Why (most) High Level Languages are Slow (article)
-
So what Skyrim's "bound" by is "running the combat AI too fast for the player to react". I guess? If you phased it that way?
Fair enough. FWIW, I can easily get GPU-bound (GTX 780) even with older games (Borderlands 2) if certain options are maxed out.
Again: the Xbox 360 has tons of games written in C# on it that are highly successful.
Sure, there are a lot of successful games that are unlikely to be bound by performance on any sane platform. Whatever. If you want to develop such a game, use whatever you want. (I'm not interested in those kinds of games, at least not as a developer.)
Graphics-intensive games OTOH, regardless of language they are written in, probably rely on GPU-side shaders. What the original blog post says is that using a C#-like language with lots of tiny heap objects would be a bad idea in that setting (since performance is still an issue there).
-
it does if you use TypeScript.
(i guess it's technically "number", not "integer" though...)Not really. Typescript still gets "compiled" into Javascript, and in Javascript numbers are still doubles, therefore you do not get integers even in Typescript, only doubles.
-
intoubles
-
-
What the original blog post says is that using a C#-like language with lots of tiny heap objects would be a bad idea in that setting (since performance is still an issue there).
It probably is.
But does that matter?
I argue: no. No it does not.
-
I'd go with
introubleswell. Thoughstringablesare even worse.That's when JS randomly decides that
1 + 1 = 11in case you didn't know.
-
-
Technically, it's a type class. And it's unnecessary (but a nice interface). GHC builds in IsString and throws in some syntactic sugar if you use it.
-
-
For anyone who wants to see if their browser is on drugs, here's some JavaScript:
var f = function() { var a = 4294967295; var b = 0; var c = a + b; console.log(c, c >>> 0); }; for (var i = 0; i < 1000000; i++) { f(); }Google Chrome is on drugs.
Edit: here, have some comments: http://www.gopherjs.org/playground/#/Ld2nurSJ-k
-
Does anyone who seriously cares about optimizing runtime performance not write in C these days?
Yes. For my project, I'm avoiding C at all costs. Instead, I use... C++
-
Well I don't play it. You tell me, is it? That's really incidental to my point, which is that it's been many years since a successful game "needed" the performance of C/C++.
Jebediah Kerman and his 1000-part space city would like to have a word with you.
-
Dwarf Fortress isn't CPU-bound, so I doubt any game with graphics would be.
-
Jebediah Kerman and his 1000-part space city would like to have a word with you.
Besides, it's funny how CPU performance apparently isn't a problem (according to @blakey), and yet there are several pushes for lighter and cheaper APIs (e.g., Mantle, and now Vulkan; and before that a whole slew of OpenGL extensions).
-
At least in Dwarf Fortress's case, the CPU spends most of its time waiting for RAM to respond. There's just too much data that is interacted with during any given frame to fit in the CPU's cache.
-
At least in Dwarf Fortress's case, the CPU spends most of its time waiting for RAM to respond. There's just too much data that is interacted with during any given frame to fit in the CPU's cache.
Having all data fit into the caches would be fairly rare in any case.
It's more about making sure that you don't get "unnecessary" cache misses - i.e., if you iterate over a set of objects, make sure that they appear in compact ranges so that you get a good benefit from the caches and prefetching (rather than spreading your objects out over the heap and potentially paying for a cache miss on every access). Also, make sure you don't pollute the cache unnecessarily by e.g. interleaving data you want to access with data you don't want to access (the whole SoA vs AoS thing). Etc etc.
In the end, the question is how easily you can control these things. Some languages (Java definitively, and apparently C# too, according to the blog post) you have to to fight on every step to do this.
-
Who the fuck in their right mind does GC on GPU, though? I'd wager GPU-bound apps are as irrelevant to the discussion as IO-bound ones.
-
In the end, the question is how easily you can control these things.
It also matters which cache you're fitting in. If your inner loop can fit in L1 I-cache and D-cache, it'll go like greased lightning. If the code doesn't fit, it'll go quite a lot slower. If the inner loop has to iterate over lots of data, it'll go much slower. (If you're paging to disk, forget speed entirely. SSDs help, but even they're nowhere near as fast as real memory, let alone any level of CPU cache.)
The problem with many languages is that they're often really not very good at respecting cache coherency. Too many programmers think of memory accesses as being free; that's only even close to true when you've got good coherency (i.e., fit in the L1 caches). Cache coherency is also why arrays are an unreasonably good data structure and why trees suck more than you'd think at first glance. This sort of thing is why people are told over and over to stop guessing and to start measuring…
-
Who the fuck in their right mind does GC on GPU, though?
Nobody that I know of so far.
I'd wager GPU-bound apps are as irrelevant to the discussion as IO-bound ones.
Not really - I'm sort-of looking for a language that has good support for heterogeneous environments. CUDA and a few others takes a steps into that direction - you have a single language where you can write code that runs on several different kinds of processors, possibly with different memory spaces (for example, I don't want to redefine my data types in several different languages - CUDA gets this right at least).
If you're designing that kind of language, you'd have to consider the problems described in the blog.
Filed under: watch out for gpuasm.js - GPU programming reinvented by the js-community
-
watch out for gpuasm.js - GPU programming reinvented by the js-community
Sweet merciful Chaos, why???
-
If the inner loop has to iterate over lots of data, it'll go much slower.
And if your data is then additionally scattered all over the place, so that you end up using only parts of the data that's loaded to the cache each read, it'll go even slower.
-
Sweet merciful Chaos, why???
Well, I don't think it exists ... yet.
For my sanity, I haven't checked, though. But yeah, you know it's gonna be written by somebody sooner or later.
-
Who needs integers on the GPU anyway?
-
Nobody that I know of so far.
Irrelevant. "People in their right mind" and "people who do GC on GPU" are non-overlapping subsets by definition.
CUDA and a few others takes a steps into that direction - you have a single language where you can write code that runs on several different kinds of processors, possibly with different memory spaces (for example, I don't want to redefine my data types in several different languages - CUDA gets this right at least).
Is it that important? You'd be rewriting all your algorithms for GPU/CUDA processing anyway.
-
Is it that important? You'd be rewriting all your algorithms for GPU/CUDA processing anyway.
It's useful for hybrid CPU-GPU algorithms where you pass data between them. (If nothing else, it saves you the inevitable face palm when your data structures get out of sync for some reason).
A few more use-cases (IMO) are:
- fundamental libraries (something like small vector stuff for example) can share large parts of code, which means maintaining less crap
- moving stuff between CPU/GPU for testing/load balancing
- debugging GPU stuff on CPU (being able to easily test/debug parts of the code and data structures helps a lot)
It also helps with porting, where you can start off by moving things to the GPU in a "dumb" fashion, and once that works, start worrying about making it run good (if that's needed).
-
Who needs integers on the GPU anyway?
You're joking, but float ops are getting much cheaper than integer ops, so... (Forget about double-precision, though. That's slow as fuck.)
-
-
I find that hard to believe...
Compare the first row to the rows 4-6.
-
I argue: no. No it does not.
Though you'll never admit it or probably even realize it, you're in agreement with the original author.
-
GPUs are massively parallel, and will have more floating-point units than integer units. Doesn't make a single float op is cheaper than a single int op.
-
GPUs are massively parallel, and will have more floating-point units than integer units. Doesn't make a single float op is cheaper than a single int op.
Partly true -- for example, integer multiplications are multiple instructions on Compute Capability 5.x cards, so a single integer mult is more expensive than a single float mult in that case.
But... when you're running on a GPU, you usually don't really care about the cost of a single instruction in isolation, but rather the total throughput (after all, you're running on a massively parallel device for a reason). Because there are fewer integer ops available, each one of them ends up being more expensive in comparison.
-
It's not about successful games, it's about high complexity graphics performance. You aren't writing that in a memory managed language.
Minecraft might sell, but it's years behind in terms of simulating graphics.
-
It's not about successful games, it's about high complexity graphics performance. You aren't writing that in a memory managed language.
In other news: you don't implement an operating system in Javascript. More at ten!
...seriously though, you can do high-complexity graphics performance in a MM language pretty well. You obviously don't get GC on a GPU, but as far as calling out to the APIs is concerned, it doesn't matter much what you're calling from.
-
It's not about successful games, it's about high complexity graphics performance. You aren't writing that in a memory managed language.
Right; but if the second doesn't lead to the first... who gives a shit?
When was the last time "looks good" was used as a selling point for a game? Crysis? I guess? That was, what, 2004?
-
The article is interesting but fairly obvious, and proves it's important to use the right tool for the job. Sometimes performance is important, but many times it really isn't. You want to put together an internal business app to manage some database? Use C#. You want to build a kernel driver that can handle 100K interrupts per second? Use C. Can you swap the roles? Probably, if you don't mind writing ten million lines of assembly/C to connect to your SQL Server, or don't mind random driver freezes because of GC cycles.
-
The article is interesting but fairly obvious
I'm not sure I agree on the obviousness. It depends on your familiarity with modern CPU design. I mean...I'm familiar with the idea of caches, but it's not necessarily the first thing I think of.
It's not even obvious to the commenters here who supposedly read the article. They keep talking about other things and ignoring the actual insights provided by actual profiling (though I think their video game fixation has played an equal role).
-
actual insights provided by actual profiling
Actual insight: it's slow and you can't do shit about it short of changing the tool for the job.
The rest is just flavor, really.
-
Um, "looks better" is where the videogame industry that matters has been heading towards forever. Cutting edge state of the art videogames thrive in progressively higher quality graphics. Of course you can sell things with old graphics, and they might even be fun and all, but I don't play Clash of Clans or Minecraft. Or at least I'm not interested in those type of games to begin with -- if that's what you mean by successful games, of course.
There are transitions, like always. Right now we're in a spot where the main development platforms (consoles) aren't really that much powerful than last generation hardware, which makes progress slower. But that doesn't mean the industry isn't headed in the same direction it's always been, even since the old 2D days.
-
The rest is just flavor, really.
Except it says why, which is important. And it also points to a way to mitigate without changing the tool but changing the way it's used. Which might or might not be worth it.
But I get it, you guys are just not very curious about how this stuff works. I'm that way about lots of things, too.
-
Um, "looks better" is where the videogame industry that matters has been heading towards forever.
Don't be fooled by today's lies. It's not that long ago that he was complaining about how terrible minecraft (and similar games) looks.
-
I'm not sure I agree on the obviousness. It depends on your familiarity with modern CPU design. I mean...I'm familiar with the idea of caches, but it's not necessarily the first thing I think of.
Okay, it might just be obvious to me because I work with a bunch of hardware engineers and firmware developers and constantly hear them complain about making things work on a 200 MHz embedded CPU.
-
Um, "looks better" is where the videogame industry that matters has been heading towards forever
Um!
I agree entirely, but its no longer a selling point and hasn't been in years.
Shadow of Mordor looks good, but it was sold on the nemesis system. Evolve looks good, but it was sold on the 4 vs 1 combat. Etc, etc.
-
Cutting edge state of the art videogames thrive in progressively higher quality graphics.
$450 million:
1.5 billion per year:
Prettier does not necessarily mean more successful anymore.
-
Um! Minecraft does look terrible. Its graphics aren't the selling-point, in fact it's a perfect example of the argument I'm making.
-
You're talking about selling points. I'm talking about good videogames.
Shadow of Mordor would have been a much worse game if it had Minecraft graphics.
(It's also not a great game by any stretch. 3 stars at most).
-
Again, I don't give a rat's ass about what sells the most. I purposefully mentioned Clash of Clans, a terrible "free" game, to make that distinction.
-
Okay, it might just be obvious to me because I work with a bunch of hardware engineers and firmware developers and constantly hear them complain about making things work on a 200 MHz embedded CPU.
Yes, I would expect someone working with those guys to be familiar with this.
the argument I'm making.
Whatever, your argument is irrelevant to this article and to me.
-
since the old 2D days.
Wow, trigger warning! I don't know if I can deal with this kind of idiocy.
Guess what? People still make 2d games! And they tend to look awesome and not have random polygons hanging out. No clipping issues. Honestly, 'looks good' is entirely subjective. Just because you love that FFVII is 3D does not mean Sephiroth is better than Kefka!
-
Duh?
You think when I typed the word "selling-point" I might have been referring to selling-points? The whole time? Shocking!
Now maybe go back and FUCKING READ the post you are replying to, moron, then come back and well talk.
-
Bonus points for missing the whole point.
People in the old days did 2D games because they couldn't do any better. They were doing exactly what state of the art 3D guys are doing right now: push the hardware to the limits to achieve better graphical fidelity -- ie, to make their stuff resemble life more and more, to get away from simple abstractions (Spacewar!) to something that connects far more directly with the player. That's exactly the same thing big bad evil AAA game making companies are doing. The fantastic games people have nostalgia for nowadays? They were the Call of Duty of the hayday. Big bad evil AAA game developers pouring enormous resources into making bigger and better games.
Indie developers nowadays do it either because they can't do 3D graphics (because they don't have the knowledge or the resources at hand to do a good 3D game) or sometimes as a marketing ploy to sell nostalgia (bad nostalgia at it -- most of the indie nostalgia platformers get the 16 bit look entierly wrong). I'm not judging -- I like game development and I would pounce at the opportunity of making my own shit. They put a lot of effort into their stuff and it's absolutely commendable. Is it cuttin edge state of the art videogames? Most certainly not.
(And now that 3D engines are far more widely available, 3D indie games are booming. Coincidence? Not at all. It's all a matter of the resources at hand to realize your vision, not an artistic statement).
