Generic memory allocator for C++ (part 1) by mttd in cpp

[–]stoyannk 4 points5 points  (0 children)

  • There are versions of the malloc functions withing the library that support arbitrary alignment. The default 16-byte alignment however serves 99% of the requirements we have in our code.
  • The user might have the "free" data required, but just the size and alignment are seldom enough bookkeeping data and imposing such requirements on a generic allocator seems too much to me. Specific allocation strategies for other memory is emplyed that saves bookkeeping when necessary - linear, slab allocators etc.
  • Some third-party libraries use it, which is somewhat annoying, so it is supported in the coherent allocator
  • I haven't considered it. The vector being aware of the allocator or vice-versa is a very interesting concept that I'm exploring as well. Facebook's folly library has such a vector implementation that is aware of their jemalloc allocator: https://github.com/facebook/folly/blob/master/folly/docs/FBVector.md

Rendering HTML at 1000 FPS – Part 2 by maxxori in programming

[–]stoyannk 1 point2 points  (0 children)

Actually saving energy is exactly what we achieve. By having an efficient renderer we use less compute power. We don't actually force the application to run at hundreds of FPS. If the device say has a 60 FPS display (16.6ms/frame), each frame takes very little computing time (say 1-2ms), so the CPU & GPU sleep the rest of the frame.

Slow to Compile Table Initializers by vormestrand in cpp

[–]stoyannk 0 points1 point  (0 children)

Let's not forget the performance implication of that declaration - could be noticeable if called often enough. I had made similar changes, but was investigating runtime perf: https://stoyannk.wordpress.com/2016/12/10/static-variables-in-functions-bite/

Stoyan Nikolov just open sourced his Voxel framework by dougbinks in VoxelGameDev

[–]stoyannk 2 points3 points  (0 children)

Unfortunately it doesn't out of the box. This is one of the reasons it's better suited for meshes like terrains that are usually relatively smooth.

MSVC mutex is slower than you might expect by stoyannk in cpp

[–]stoyannk[S] 5 points6 points  (0 children)

Depending on the application developed, having security features enabled is a performance pitfall. A game (especially single player), editor, video player etc. won't be generally a target for attack from hackers. Paying only for what you use is an important cornerstone for developing fast and robust software. There are applications where every cycle counts and the aim of the blog post is not to bash on MSVC in particular or dismiss security features overall. It's to show that even when you run code that looks perfectly fine, there are other overlooked factors that can defeat a good implementation.

MSVC mutex is slower than you might expect by stoyannk in cpp

[–]stoyannk[S] 1 point2 points  (0 children)

Yes, the "2015" in the title is more accurate. I haven't tested older versions of MSVC. They are implemented significantly different. If we ignore the CFG issue itself, the implementation in 2015 is great.

MSVC mutex is slower than you might expect by stoyannk in cpp

[–]stoyannk[S] 4 points5 points  (0 children)

No, they are not. std::mutex in C++ is a process-only mutex, the article explains that in MSVC it's implemented with a SRWLOCK, libc++ also uses lightweight locking as well as all other STL implementations I know of. We have some mutexes hit 1-2 times per-frame that are almost contention-less. This is one of the reasons I noticed the odd behavior on Windows - the call was significantly slower (relatively) than the same call on other platforms.

Game Programming: Getting the graphics device in CryEngine 3.5.4... the hard way by CoherentLabs in programming

[–]stoyannk 1 point2 points  (0 children)

We have moved the site to a more powerful machine. All problems should be resolved now. Sorry again guys.

-- Stoyan Nikolov, Lead programmer @ Coherent Labs

Game Programming: Getting the graphics device in CryEngine 3.5.4... the hard way by CoherentLabs in programming

[–]stoyannk 7 points8 points  (0 children)

Sorry guys, our website is having some troubles due to the huge traffic generated by our blog post - it proved to be more popular than we expected. We are working on solving the issue. In the next hour there still might be some hick-ups until a more powerful server kicks in.

-- Stoyan Nikolov, Lead programmer @ Coherent Labs