Tobba_

To clarify: that's more of a problem in programming the GPU in a portable manner, and that may or may not turn into a problem depending on the implementation. GPUs can do loops that run a different number of times per thread just fine, at the cost of having to wait for the slowest to finish. Things start to turn sideways if you want diverging branches though (at least AMD kind of has support for this, but it's limited). If you want animations to work there's a good chance your search would become pretty complicated and you run the risk of smacking into that.

Also, I doubt GPU vendors would add special-purpose hardware like that. They'd much rather just add some new shader instructions to help doing it.

Yep. There's a billion and a half reasons you wouldn't use full-blown path tracing for games. It'll always perform worse regardless of what you do, the frame budgeting is likely going to be a total nightmare, the tree search you need to trace rays requires too much branching to map well to GPUs (it's perfectly possible, just another absolute nightmare as your complexity goes up), console GPUs are (and have always been) extremely underpowered in terms of compute (but good with textures), etc.

Limited uses? Sure. Otherwise hell no. It's never been more than a gimmick GPU vendors use to show off (in real-time, offline rendering is something else entirely).

I'm sure that pile of data will gain intelligence if we stir it hard enough. Any moment now.

It'd help a lot if the grammar was actually readable. Combinations like .* don't visually "read" like a single unit, and then to make everything worse you often need a crazy amount of backslashes.

I'm not sure how you could fix that without introducing completely new characters or color-coding parts of the expression though.

It's a completely meaningless and plain stupid argument though. There's no reason to believe human consciousness is special and that "understanding" Chinese is at all related to it. One can speculate that the perception of consciousness is simply the product of some form of introspective sensory system and internally-directed actions, of which the former ironically clearly doesn't quite work when it comes to language (or it wouldn't be as much of a reverse-engineering exercise). Nothing really stops you from throwing that into your system and having it consciously understand chinese, assuming it already maintains state.

You can however make a fairly solid argument that a CNN alone (as used in image/object recognition) is fundamentally incapable of dealing with images (but maybe not language), on the assumption that it can be faithfully described as Satan's boolean satisfiability problem, then by virtue of complexity theory it can only be solved in constant time with a sufficiently massive lookup table (which there wouldn't be enough atoms in the universe to store). Microsoft are actually dealing with this in their system by repeatedly applying the network and revisioning the text.

Regardless though, accurate NLP is going to come down to managing to codify how humans deals with objects, concepts and actions, because that's what the languages encode; GOFAI wasn't really too off (and the original effort was doomed from the start by the state of hardware and linguistics). Consider how distinguishing objects as masculine-feminine-neuter and animate-inanimate(-human) is universal (but doesn't necessarily affect the grammar), and that the latter is based purely on how complex/incomprehensible the behaviour of something is (unlike grammatical gender which seems to be fairly arbitrary). Of course that's arguable, but you can see animacy appear in english word choices (unrelated to anthromorphic metaphors) and in how "animate" objects tend to be referred to as having intent. You could try and figure all this out the wrong way around using statistical brute force and copious amounts of text, but that's pretty roundabout isn't it?

(Also, the assumption that an objects animacy is determined by predictability offers a pretty concise explanation of why the idea of human consciousness being produced by simpl(er) interacting systems often fails to compute so spectacularily, why most programmers appear to be immune to that, and also why the illusion that image recognition CNNs perform their intended function is so strong (regardless of how useful they are, the failures make it blatant that they're only looking at texture and low-level features, and are extremely sensitive to noise, which is the opposite of what anyone intended))

I think the difficulty in 3D polygon modelling is partially a tooling problem, and also a learning curve problem. The usual workflows I've seen/used that didn't involve sculpting (which requires being good at that too) all involve blocking out the model in several steps and applying semi-irreversible transformations, making it really hard to go back and fix a dumb mistake. Some editors like Blender are also notorious for having completely impenetreble interfaces, and even 3ds max and similar probably aren't too straightforward either. Ontop of all that, you're required to know a ton of technical details (skinning, normal smoothing, etc) that aren't explained properly for modellers anywhere I know of (building an engine/renderer is a fairly direct way to pick up that knowledge though).

3D sculpting and CAD modelling are entirely different beasts however (I've never actually seen CAD tools involved in a game asset workflow, but it could be done and would be fairly useful for inorganic assets). Sculpting is dead simple in principle, in the same sense that drawing is; meaning you don't need to worry about the tools in the same way. CAD is a different beast, but still works on some pretty simple principles (constraint-driven CSG).

I think the only real "hard" part right now is getting low-poly versions of assets that can be used inside of your engine. Making the high-poly assets might require more actual work (and 3D scanning could help there), but it's nonetheless fairly straightforward.

edit: "low-poly" here meaning "reasonable number of polygons", not visibly low-poly.

To attempt to explain (desktop) GPU architecture: you don't just have memory and a bunch of individual cores on a GPU like you would on a CPU. You've got memory, texture sampling units, various other fetch units, fixed-function blending/output units, raster units, a dispatcher and then a ton of processing elements. These are all things the programmer need to set up (through the graphics API). Each of those processing elements runs several warps (wavefronts in AMD terminology), each which contains 32 or 64 threads (vendor-dependent), that all have their own set of registers. The warp holds the actual instruction stream and can issue operations that occur on all or some of those threads. Branching is possible, but pretty limited unless it's the same for every invocation. So the programming styles/models are incompatible from the start.

Then the real problem is, since all shader invocations share those fixed-function units, if you need to reconfigure them to use a different set of textures, buffers, shaders, etc you have to bring the whole operation to a complete halt, reconfigure it and restart it. And, contrary to popular belief, GPUs are the exact opposite of fast - each shader invocation takes an enormous amount of time to run, which is traded for throughput. Stopping that thing means having to wait for the last pieces of work to trickle through (and then when starting back up, you have to wait for enough work to be pushed through that all the hardware can be used efficiently), which means a lot of time doing little work.

So if you're trying to deal with the above, any notion of keeping things separate and clean (in terms of what the hardware sees, anyways) immedietely goes out the window. That's why things like virtual texturing exist - to let you more or less pack every single texture you need into a single gargantuan texture and draw as much as possible using some God-shader (and also because heavy reliance on textures tends to work well on consoles). Then you also have to manage to make good use of those fixed-function units (which is where tiled rasterizers on mobile GPUs can become a problem), but that's a relatively separate thing.

Also: transfering data back and forth in itself isn't necessarily that bad in my experience (just finnicky), it's usually the delays and synchronization that gets you.

Vulkan is almost 1:1 equivalent to "modern" OpenGL except the need for a more advanced allocator. You had to write the exact same thing in OpenGL if you wanted decent performance, except through an entire translation layer.

I don't think anyone who actually worked on a serious engine thinks it's somehow harder to use. Sure, there's more boilerplate and it might get pretty difficult to port something to it, but that's something else entirely.

CS:GO (and all other source games) do the same lag compensation as CS did (though it's horrifically buggy, but it was pretty messed up in 1.6 as well). People seriously underestimate how impossible it is to play fast-paced games without it - you wouldn't be able to hit a HS on a moving player in CS:GO even with ~30ms ping without leading your shot if that wasn't there.

It's also not actually why you rubberband - that's just caused by your own latency (moving while already dead). It does mean you can get hit after moving behind a wall though.

It's great to actually see a game developer that seems to have some grip on what they're doing. At least writing about issues like clocking, animation quantization, etc is far better than what everyone else does - screwing it up and never fixing it. It's not all perfect, but still(I don't play LoL though).

CS(:GO) would be completely unplayable at any update rate below 50. Especially with the necessary interpolation, you would end up with delays of over 100-200ms+ at an update rate around 10. Most weapons in the game could even fire more than one shot in that time.

It does have a slight advantage over ARM / most other RISC architectures in that the instructions are fairly small, meaning that you can get quite good decoding throughput without going wider. That advantage doesn't get entirely cancelled out by how badly allocated things are, since instructions can decode to multiple "actual" instructions (µops).

I'm still curious as to how Intel thought a mobile x86 chip could ever work.

While they're certainly the correct way of doing this, named pipes don't provide too many benefits under Win32; other than this little problem and having to assign a port number, of course. They're harder to debug, require a whole new slew of I/O boilerplate ontop of your existing files/TCP/UDP sockets, suffer from a bunch of weirdness when connecting, etc.

They're also pretty slow, but that isn't much of a concern here - browsers do suffer from it though (except for Edge, which uses an undocumented IPC API).

Enemy AI is most certainly the perfectly wrong place to apply ML due to the wide range of possible inputs (scenarios) and being in the utterly wrong complexity class (I mean, it's ostensibly doable with an RNN, but definitely not worth it).

GOAP is still pretty much the end-all of game AI, but it can be pretty tricky to work with.

Machine learning really doesn't have many uses for games outside of the development cycle (or non-critical gimmicks). If it's exposed to player input - or especially; random input - it absolutely must have robust, stable and controllable behaviour, at least on paper. Most of the time getting any of those out of an NN is either difficult or blatantly impossible.

Though speech synthesis specifically might be a good use case for some simpler ML, such as to form the final sound from processed phonemes (i.e acting as a fuzzy lookup table).

Doesn't really make the interface any less crap; though I've yet to see a GUI that didn't shell out to the command-line interface (which almost always makes them very unreliable).

You'll still get an increase in the number of things you can have loaded into RAM at once that's proportional to the reduction. That'll give you far more leeway in when trying to load resources on the fly, which most games still struggle with. So reducing memory usage is definitely something you want to do regardless of how much you have.

Also, if it's a PC game, you're looking at memory limits far below what the HW may offer - at least if you want it to run without annoyances. Windows limits the amount of memory it'll allow to be committed to the DRAM size + (current) pagefile size (may only be 4-8GB on SSDs); note how that doesn't include GPU memory - and allocating that counts as commit due to how residency works. Then you're looking at the OS eating 2-3GB of that, plus 1+GB if the user has a browser opened, plus anything slowly leaking memory. And a LOT of recent Windows applications leak memory or actually use insane amounts (including, amazingly, a built-in service on Win10) - if they never access it again it'll eventually get evicted from the working set, which means it only counts towards committed memory; task manager doesn't display per-process committed memory by default. That's only a fraction of all the problems.

There isn't really any practical reason for most sites to support users with JS disabled, as they're a pretty small minority. So there isn't really any good reason sites or users would actually care about or bother making the distinction.

Just make a separate "document web", with a standard that isn't utterly lovecraftian and has all the functionality that current ostensibly "document-only" sites (i.e news, forums, etc) rely on JS for. Then, disguise it inside some hip web framework where the client end just acts as a viewer, client-side rendering to boot (with a fallback for users with JS disabled). Make sure an independent implementation can access the underlying "document" through the endpoints the clientside rendering uses. Now you're able to essentially fool people into supporting it.

Also, you could choose to represent your document sites as a pile of data and non-Turing-complete "scripts" that do the presentation, with state that can only change upon user interaction. That may seem like a really backwards way of doing it, but if done right, it would give you a really good bang for the buck in terms of functionality/UX vs implementation complexity.

What's wrong with the evolution of OpenGL? Everything from OpenGL 3 and on has simply been focused on fixing the API without completely breaking old code, or exposing new GPU features. All of that was necessary.

You could just ..uh.. acquire a copy of IDA that has the AMD64 decompiler. It's more mature and spits out C code of wildly varying readability, though only for one function at a time.

Doesn't look that way? https://github.com/avast-tl/retdec/blob/master/src/bin2llvmi...

Capstone would probably be the best open-source choice for something like this though.

Looks like it's also relying on LLVM for disassembly? Ouch; that's an incredibly bad idea if you're trying to analyze malicious or unusual code (it's not designed for that), but I guess it's the easiest for a proof of concept like this.

Although, there's no way an AV company doesn't have its own disassembler, but those are almost always treated as trade secrets (especially the stuff that isn't in the spec / the spec is wrong). They'll probably hook it up to that before doing any real work with it themselves.

Unless, somehow, every one of those sockets happened to share the same port on said machine, say... port 80. So yes, you need to use the mythological TCP server to pull this one off; it's true that you can't have more than 2^15 outbound connections from the same IP though.

I guess what I'm really trying to say is that the performance of the "distributed" part has more to do with the design of the algorithm and less to do with the implementation (i.e Elixir). It's like saying Teslas have really impressive electric motors and entirely ignoring the rest.

Their blog (the part GP was referring to anyways), which I'll admit I've only read a portion of, seems to mostly talk about the message-shuffling portion of it though, and a lot of it is just discusses working around their architecture being utterly ridiculous. Once you've figured out where the messages actually need to go though, chucking them out (or the fanout, if you want to call it that) is pretty clearly a trivial operation. And, at least in theory, the routing would only change when a user/node joins/leaves, so the volumes involved there aren't quite as heroic as the message volumes. Handling a few thousand join/leaves per second doesn't sound quite as... scaling, though. I don't think they even bother trying to keep them in perfect order.

Again though, I'm not trying to say that it's not impressive that they got it to work, I just wanted to point out how we seem to have gone backwards / forgotten in terms of handling large volumes of traffic.

E: You're definitely right that HTTP connections are a pretty poor choice of comparison for messaging though.

I can definitely agree with it being easy to use at least. I'd figure that's the main reason it's as popular as it is (together with the feature set, of course).

Being able to click a link and simply join a channel without all the fudging it can take when using TeamSpeak or even IRC is great, not to mention how easy it makes setting up your own "server".

Have we really regressed to the point where simply relaying data with reasonable performance is considered impressive? Figuring out where to relay everything and keeping it all in sync is obviously hard, but that's a distributed systems problem, not (strictly) a performance problem.

We've been able to handle millions of concurrent HTTP(!) connections on a single machine for years; it feels like a pretty solved problem. Although, a lot of that involved userspace TCP stacks and really high-end networking hardware, so if you want to stay within saner territories you can scale that number back a bit.

It tends to fail to register the key being released for one, even occasionally on the desktop client.

Last time I tried it the browser app was especially prone to this, to the point of rendering push-to-talk completely unusable.

I wouldn't really say their client works in that sense considering how notorious it is for flunking out in completely random ways (i.e missing push-to-talk release events, suddenly deciding your speakers or mic don't exist, not lighting up people who are speaking, the UI randomly blanking out, etc). It's probably the worst of the bunch in terms of bugs other than maybe Skype. Not that anyone picks their chat/VoIP client based off that either way; we all happily used the 2011-era Steam client, and that was a legendary kind of awful.

Also, I can't be the only one who can single out Electron/CEF apps just from how bad the input delay is. It gives me the feeling of it being made of cheap plastic.

Unit testing seems to frequently result in overconfidence.

Pre-MIR, I'm fairly sure the people who would touch the type/lifetime checker could be counted on one hand, and it was borderline obfuscated due to all the pointless type theory thrown around.

RFCs would still get rejected as "postponed" if it wasn't possible to implement them (i.e dependent on MIR). Implementability was the deciding factor from what I could see, though compiler improvements would usually render them un-postponed/rejected later.

Overall I think the lack of an actual specification hamstrung it real bad, since everything past one step ahead only existed in peoples heads. And, at least me for me, it can't replace C++ (in every situation) as much as I'd prefer not to have to use that abomination of a language.