8 ms·

Besides, CPUs are only optimized for games if you write your code to take advantage of it. I worked on AAA engines that completely disregarded caches and branc

Besides, CPUs are only optimized for games if you write your code to take advantage of it. I worked on AAA engines that completely disregarded caches and branch prediction and while that worked great 10 years ago the same architecture became crippled on modern CPUs. Its so very easy to trash CPU resources that at this point I'm convinced most programs easily waste 90% of their CPU time. For the last AAA title I shipped we spent weeks optimizing the threads scheduling, priorities and affinities along with profiling and whatnot; it was still an incredible challenge to use the main core above 80% and the other cores above 60%. If your architecture doesn't take the hardware into account from the ground up, you're not going to fully use the hardware :)

repsilat 10y ago
> I'm convinced most programs easily waste 90% of their CPU time. Hah, in my experience that's hopelessly optimistic. The C I write is probably 10-100x slower than it should be (leaving SSE and threading aside entirely), but the Python I write most days is a hundred times slower still.
- Radim 10y ago
  One data point to support your claim: * pure Python: 1.0x (baseline) * NumPy (numeric python): 120x * Google-optimized pure C: 2,500x * optimized Python + Cython + BLAS: 8,700x This is optimizing the same numeric algorithm (word2vec) using different languages and tricks, from naive pure-Python down to compiled Cython with optimized CPU-specific assembly/Fortran (BLAS) for the hotspots [0]. [0] http://rare-technologies.com/word2vec-in-python-part-two-optimizing/ http://rare-technologies.com/word2vec-in-python-part-two-opt...
  - flamedoge 10y ago
    and I'm sure pure Fortran would be even faster
    - eru 10y ago
      That's mostly because of Fortran doesn't have the same aliasing trouble as C?
      - flamedoge 10y ago
        Pointer indirection is expensive tradeoff for flexibility
    - deleted 10y ago
      [deleted]
    - alfalfasprout 10y ago
      Eh, doubtful. Sure, it'll be faster than unoptimized C. But when you observe strict aliasing rules in C a modern compiler will generally produce similar quality assembly for both languages. The reason BLAS is so fast is that every single line of code in a hot loop has been hand-optimized and tons of CPU-specific optimizations exist Fortran yields some of the fastest code out of the box, yes, but C/C++ can yield equivalent performance by adhering to certain basic rules.
      - flamedoge 10y ago
        Even with strict aliasing, the only way C/C++ standard effectively lets one type to be cast to another is incurring a copy. Tell me what can be done better for performance in C that can't be done in Fortran or "another static language without pointer indirection".
- jeremiep 10y ago
  You can get a lot of performance back just by taking branch predictions and cache misses into your designs. I did just that in C# last years and got at least two orders of magnitude of performance gain from it. Still, I constantly wished I was working in C instead :)
munificent 10y ago
There is a potential counter-argument that this is because multicore is an example of a CPU feature that was not designed for videogames. :) I don't know if that's strictly true, but I do feel games aren't as easy to split across threads/cores as many other types of software. Ultimately, a game boils down to one big giant blob of highly mutable and intertwined state (the world) that is modified very frequently with very low latency and where all reads should show a consistent view. In other domains, avoiding interaction between different parts of your application state is a good thing that leads to easier maintenance and often better behavior. In a game, the whole point is having a rich world where entities in it interact with each other in interesting ways.
- panic 10y ago
  If you're interested in how a game might use multiple cores, this GDC talk is worth a watch: http://www.gdcvault.com/play/1022186/Parallelizing-the-Naughty-Dog-Engine http://www.gdcvault.com/play/1022186/Parallelizing-the-Naugh...
  - elmindreda 10y ago
    This one is quite good too: http://gdcvault.com/play/1021926/Destiny-s-Multithreaded-Rendering http://gdcvault.com/play/1021926/Destiny-s-Multithreaded-Ren...
- _pmf_ 10y ago
  > There is a potential counter-argument that this is because multicore is an example of a CPU feature that was not designed for videogames. That's a common trope; it mostly applies to the rendering path. AI / Physic engines are nicely scalable with the number of cores (AI in particular, because a) it's oftern agent based, which naturally work concurrently and b) with AI, slighly relaxed synchronization constraints sometimes generate some desirable degrees of fuzziness and unpredictability ... although this is probably a very slippery slope ...)
- daemin 10y ago
  To me the whole view of the game world being a "giant blob of highly mutable and intertwined state" stems from the fact that for over a decade all games had to do was have an update and a render pass in the main loop. So you could have a big mess because all of the world updates were serial, and so the developers didn't really experience the problems arising from such design. Now it takes a change in perspective on how to structure code and data to properly exploit multiple cores to their full potential. It is certainly possible to have interaction in the game world and do it in a multi-core multi-threaded way, it just needs smarter structures and better organisation of data. Game developers have and will adapt to this.
FeepingCreature 10y ago
Yes well maybe if Intel's cool toolkit to highlight cache issues didn't cost more than a hobbyist could plausibly justify...
- jeremiep 10y ago
  Its far worse than that. Even PC games are often optimized by hardware vendors rather than the actual developers. See http://www.gamedev.net/topic/666419-what-are-your-opinions-on-dx12vulkanmantle/#entry5215019 http://www.gamedev.net/topic/666419-what-are-your-opinions-o... On consoles we get access to the hardware specs and profilers for everything - even if behind huge paywalls and confidentiality contracts. Yet with all that information available its still insanely hard to optimize the codebase. There's absolutely no incentive to push these tools/specs to hobbyists because even professionals have a hard time getting them. Its also worth mentioning that having access to the tools and specs doesn't mean you'll understand how to properly use them.

repsilat 10y ago

> I'm convinced most programs easily waste 90% of their CPU time. Hah, in my experience that's hopelessly optimistic. The C I write is probably 10-100x slower than it should be (leaving SSE and threading aside entirely), but the Python I write most days is a hundred times slower still.

Radim 10y ago
One data point to support your claim: * pure Python: 1.0x (baseline) * NumPy (numeric python): 120x * Google-optimized pure C: 2,500x * optimized Python + Cython + BLAS: 8,700x This is optimizing the same numeric algorithm (word2vec) using different languages and tricks, from naive pure-Python down to compiled Cython with optimized CPU-specific assembly/Fortran (BLAS) for the hotspots [0]. [0] http://rare-technologies.com/word2vec-in-python-part-two-optimizing/ http://rare-technologies.com/word2vec-in-python-part-two-opt...
- flamedoge 10y ago
  and I'm sure pure Fortran would be even faster
  - eru 10y ago
    That's mostly because of Fortran doesn't have the same aliasing trouble as C?
    - flamedoge 10y ago
      Pointer indirection is expensive tradeoff for flexibility
  - deleted 10y ago
    [deleted]
  - alfalfasprout 10y ago
    Eh, doubtful. Sure, it'll be faster than unoptimized C. But when you observe strict aliasing rules in C a modern compiler will generally produce similar quality assembly for both languages. The reason BLAS is so fast is that every single line of code in a hot loop has been hand-optimized and tons of CPU-specific optimizations exist Fortran yields some of the fastest code out of the box, yes, but C/C++ can yield equivalent performance by adhering to certain basic rules.
    - flamedoge 10y ago
      Even with strict aliasing, the only way C/C++ standard effectively lets one type to be cast to another is incurring a copy. Tell me what can be done better for performance in C that can't be done in Fortran or "another static language without pointer indirection".
jeremiep 10y ago
You can get a lot of performance back just by taking branch predictions and cache misses into your designs. I did just that in C# last years and got at least two orders of magnitude of performance gain from it. Still, I constantly wished I was working in C instead :)

munificent 10y ago

There is a potential counter-argument that this is because multicore is an example of a CPU feature that was not designed for videogames. :) I don't know if that's strictly true, but I do feel games aren't as easy to split across threads/cores as many other types of software. Ultimately, a game boils down to one big giant blob of highly mutable and intertwined state (the world) that is modified very frequently with very low latency and where all reads should show a consistent view. In other domains, avoiding interaction between different parts of your application state is a good thing that leads to easier maintenance and often better behavior. In a game, the whole point is having a rich world where entities in it interact with each other in interesting ways.

panic 10y ago
If you're interested in how a game might use multiple cores, this GDC talk is worth a watch: http://www.gdcvault.com/play/1022186/Parallelizing-the-Naughty-Dog-Engine http://www.gdcvault.com/play/1022186/Parallelizing-the-Naugh...
- elmindreda 10y ago
  This one is quite good too: http://gdcvault.com/play/1021926/Destiny-s-Multithreaded-Rendering http://gdcvault.com/play/1021926/Destiny-s-Multithreaded-Ren...
_pmf_ 10y ago
> There is a potential counter-argument that this is because multicore is an example of a CPU feature that was not designed for videogames. That's a common trope; it mostly applies to the rendering path. AI / Physic engines are nicely scalable with the number of cores (AI in particular, because a) it's oftern agent based, which naturally work concurrently and b) with AI, slighly relaxed synchronization constraints sometimes generate some desirable degrees of fuzziness and unpredictability ... although this is probably a very slippery slope ...)
daemin 10y ago
To me the whole view of the game world being a "giant blob of highly mutable and intertwined state" stems from the fact that for over a decade all games had to do was have an update and a render pass in the main loop. So you could have a big mess because all of the world updates were serial, and so the developers didn't really experience the problems arising from such design. Now it takes a change in perspective on how to structure code and data to properly exploit multiple cores to their full potential. It is certainly possible to have interaction in the game world and do it in a multi-core multi-threaded way, it just needs smarter structures and better organisation of data. Game developers have and will adapt to this.

FeepingCreature 10y ago

Yes well maybe if Intel's cool toolkit to highlight cache issues didn't cost more than a hobbyist could plausibly justify...

jeremiep 10y ago
Its far worse than that. Even PC games are often optimized by hardware vendors rather than the actual developers. See http://www.gamedev.net/topic/666419-what-are-your-opinions-on-dx12vulkanmantle/#entry5215019 http://www.gamedev.net/topic/666419-what-are-your-opinions-o... On consoles we get access to the hardware specs and profilers for everything - even if behind huge paywalls and confidentiality contracts. Yet with all that information available its still insanely hard to optimize the codebase. There's absolutely no incentive to push these tools/specs to hobbyists because even professionals have a hard time getting them. Its also worth mentioning that having access to the tools and specs doesn't mean you'll understand how to properly use them.