6 ms·
I don't necessarily agree that it's a problem of the language ecosystems. In my experience games are one of the few areas where it is likely to be CPU bottlenec
by munchbunny 10y ago
I don't necessarily agree that it's a problem of the language ecosystems. In my experience games are one of the few areas where it is likely to be CPU bottlenecked and not I/O bottlenecked.
My sample size is only the set of projects that I've personally worked on, but in the projects where I have intentionally profiled where the time is being spent, I have only ever run into UX-impacting CPU bottlenecks when working on games. This is spanning code I've written from assembly all the way up to Python. Not counting JS because the DOM is a bit of a black box to me. In almost every other case, the bottleneck was not being able to pull data out of physical storage or some network store fast enough. In some cases it was not being able to pull data from RAM fast enough. In a few cases it was not being able to pull data from a database fast enough due to needing to cover too big of a table, which I lump into the "waiting for I/O" category under the lightly investigated hypothesis that it's not because the CPU is having trouble iterating over the indices, but because the database can't keep the whole index in memory.
- koolba 10y ago> My sample size is only the set of projects that I've personally worked on, but in the projects where I have intentionally profiled where the time is being spent, I have only ever run into UX-impacting CPU bottlenecks when working on games. Try out any "enterprise" app that thinks its a good idea to load 25,000 widgets on one page. That'll show you the meaning of "CPU bottleneck".
- wolfgke 10y ago> Try out any "enterprise" app that thinks its a good idea to load 25,000 widgets on one page. That'll show you the meaning of "CPU bottleneck". Depending on the implementation it might also be a GPU bottleneck.
- nitrogen 10y agoIt's pretty crazy how video games can display thousands of objects and millions of vertices at 100+fps, yet web browsers and applications can struggle to display more than a handful.
- pcwalton 10y agoYep. That's largely because 2D vector graphics APIs from the '90s are poor fits for GPUs (and stream processors in general, really).
- Tloewald 10y agoIf you have a look at the code on many websites the answer is ludicrous amounts of bloat.
- ssalazar 10y agoIts not crazy when you consider typical video game economics (hundreds of developers/long dev time/high budgets/high price per unit) vs. typical website economics (handful of developers at best/short dev time/low budget/microscopic price per "unit"). Video games are often intimately tied to the underlying hardware/software stack allowing further optimization whereas the same webpage can often operate unaltered on a multitude of devices. And video games are often judged by how many "objects and vertices" they can show and how fast they can show them, whereas websites have other criteria.
- sbierwagen 10y agoThat's because the video game engines doesn't have to be hardened against malicious asset files. All the code in a video game runs at the same permissions level, which you definitely can't say about a random page on cnn.com.
- zubat 10y agoBrowser content has to support all the features and they add up pretty quickly. For example a large scrolling list with thousands of items can be solved by a gamedev by mandating all content be the same size and applying a tiling rule. A list in a webapp is likely to be held to a higher standard and so needs to consider heuristics to find the position of content, dynamic updates, etc.
- Qwertious 10y agoThat's what 10+ full-time engine devs working full-time on the project from the start can get you, I suppose.
- MichaelGG 10y agoI've seen a page that just displayed a grid of images. It took seconds of CPU time on an i7. The page doubled its load time if you had CPU throttling. I'm not sure what the ultimate reason was, but the end result was that, as far as the user saw, the page did a fancier looking <table> and required billions of cycles to do so.
- squeaky-clean 10y agoWhile that technically may be a cpu bottleneck, I like to look at it as an implementation bottleneck. I can write a pong game that will be bottlenecked by any cpu if I make it calculate a million digits of pi at the start of each game loop, but it doesn't mean my game is more hardcore than Crysis.
- MichaelGG 10y agoIt's obviously an implementation issue. The question is how do otherwise sane-appearing individuals end up writing code like that? How does it even pass a preliminary usage test? And so on. This wasn't some big enterprise, either.
- other_herbert 10y agoThat question haunts all of us... For instance... Lets say you need to query a db to get 4 known sets of things aggregated by other things... That should scream at you "in clause with the known params and group by" or.... if you take an approach I saw recently you spawn 4 worker threads each querying the same tables but with one of those 4 params then combining the records.... I'm afraid this board may constitute the remaining sane individuals... Edit those known params were all used as a param for the same column
- munchbunny 10y agoTrue, but in cases like that it seems like the CPU is hardly the problem in the big picture. ;) Sounds like you and I mostly agree. Just that when you do a root cause analysis, "more efficient CPU usage" seems to rarely be the best place to optimize, compared to "do less I/O" or "stop putting 25,000 widgets on one page", or "smaller RAM footprint", and so on.
- pcwalton 10y ago> In my experience games are one of the few areas where it is likely to be CPU bottlenecked and not I/O bottlenecked. Agreed, in most cases. That's why I'm not sure what I described is really a problem :) (I do think that mobile apps and the client-side portion of Web apps, for example, are often CPU/GPU-bottlenecked, though.)
- munchbunny 10y agoYou're right, I think we generally agree. I was just picking at a nuance of what you said about wasted CPU cycles. Yes, some languages and toolchains these days are less efficient to trade for ease of development, but from my experience it seems like I/O to RAM/disk/network is still 80% of the problem and "less work per CPU instruction" is 20% of the problem.
- Retric 10y agoI have seen plenty of 10x speedups in most apps from trivial changes. If you fail to use CPU cache correctly then can be getting ~1% utilization or less per logical CPU which is still plenty fast for the core logic of many applications.