search

tyoma / agge

Anti-Grain Evolution. 2D graphics engine for Speed and Quality in C++.
MIT License
117 stars 17 forks source link

Anti-Grain Evolution ! #2

Closed Remotion closed 5 years ago

Remotion commented 5 years ago

Really happy to see Anti-Grain Evolution ! Thank you for this !

Do you have any plans to use C++17 or at least C++14 for it ? Asking this because there are bunch of std::auto_ptr in the code and other pre C++11 code.

tyoma commented 5 years ago

Hi! Thanks for the interest.

The core library (not the text rendeder) is C++03-compliant and will stay that way - it has nothing to do with library's performance or features or the ability of the library to be included into c++11+ projects. The auto_ptr's you have seen are located either in tests or in samples - I'll get rid of auto_ptr(s) sooner rather than later - thanks for noting it!

There's one important thing about its development - the language features are employed by the project as they needed, not simply because they exist. Approach like this guarantees great portability options across different compilers.

I'll keep this one opened until obsolete stuff is removed. Thanks again!

tyoma commented 5 years ago

Hi! I've pushed changes that address auto_ptr usage except for the agge.async library - I haven't decided on the design yet. Once it done, no deprecated will be used there. I had to add scoped_ptr to tests, though, as compilation under c++03 must be supported. The philosophy behind my decision is fairly simple - to maintain portability I'm using as narrow set of c++ features as possible, otherwise I'm alone won't be able to have it compatible with MSVC, GCC and Clang and have MacOSX, Windows, Linux (and Android) supported. It is important to note, that the library interface is designed with a balance between 1) ease of use 2) maximum closeness of the abstractions to functionality 3) the narrowest possible language feature set. There are no limitations in using it from any newer c++ standard code.

Remotion commented 5 years ago

Hi! Thank you very much.

I understand what you mean, but I am still wondering how many platforms still do not have C++11 compiler.

tyoma commented 5 years ago

It's not necessarily the platforms. Some businesses are pretty conservative in their toolset (or event feature set within toolset - look at Google, they don't use exceptions even in places, where exceptions make perfect sense). Plus, modernizing of compilers doesn't necessarily make them faster. For instance if you compile agge with VS 2010, VS2013 and VS2017 you'll notice that 2010 and 2017 produce faster code than 2013. It surprised me first, but then comparing assemblies produced I've found out that 2013 inserts rep-prefixed stos here: https://github.com/tyoma/agge/blob/a8466972576dafadeed12878e944c45f1c2352a6/agge/scanline.h#L59, instead of SIMD-optimized memset() in VS2010. And rep stos is dramatically slower even on modern Intel CPUs, because of the bootstrapping of that instruction (unexpectedly it has quite complex microcode, it's superfast with arrays larger than 1000 bytes, but sucks with 10s to 100s, which is the case in agge). Another thing - take a look at what atomics look like in MSVC. It turns atomic compareexchange* into long spaghetti of branching, which is heavy for CPU and you end up with twice a slowering (lock prefix is heavy itself, since it implies store buffer flushes on x86) than you would if only cmpxchg is used. So, yeah, instead of cutting off the way to use of these compilers, I prefer a realtively small sacrifice in the tools usage.