Why doesn't Irrlicht use STL?

[hybrid]

Well, benchmarks are usually good for markteing reasons, and to know which benchmark runs faster. But there's usually not much more to get from.
Moreover, a proper speedup of Irrlicht which would only come from a changed implementation of the container classes (so no algorithm changes underneath) would mean that your app is doing almost every time consuming caclulation inside container classes, but most render applications are slowed down due to rendering or at least communication with the gfx card. So even if you find some container intensive algorithm which would run ten times faster with STL compared to Irrlicht containers, I doubt that you'll find it in any 3d render application, and even if you'd do so it would probably still not be the limiting hotspot.
Moreover, the speed increase would still be seen if you keep the existing interface and only use STL behind the scenes.

[Dorth]

Btw, checked the Unreal engine. They don't use STL but containers emulating them. When asked about it, they said it was legacy. If they did the engine today, they would go with STL, but in 1999 (!) the STL was not everywhere, not compliant and slow. So yeah, their point make sense, but our engine is not that old, certainly not that used and quite frankly, their implementation is top notch. Anyway, I gotta give it to rogerborg, the "faster" claim isn't backed either, my apologies. It'd be nice to test anyway. But for now, a wrapper would be good. And rogerborg, it just so happen I also have a day/night job like the devs, so an argument take what 5 mins and can be constructive, that patch can take ??? time for building and testing.

[rogerborg]

Don't get me wrong, I fully expect an STL implementation to be faster and I have a mild preference for Irrlicht to use STL. Not enough of a preference to risk regressing any functionality though, as I also agree with hybrid that in most cases there won't be any significant speedup.

That's just a "belief" though.

[agi_shi]

So even if you find some container intensive algorithm which would run ten times faster with STL compared to Irrlicht containers, I doubt that you'll find it in any 3d render application, and even if you'd do so it would probably still not be the limiting hotspot.

The problem here, is that Irrlicht seems to be geared towards lower-end computers: computers with less powerful graphics, where more and more is done on the CPU. Heck, Irrlicht even has completely software-based rendering. In cases like these, this "minimal" speed increase is crucial.

Moreover, the speed increase would still be seen if you keep the existing interface and only use STL behind the scenes.

No, it wouldn't - the increased overhead of arbitrary non-STL functions will cause troubles.

[CuteAlien]

Ok, simply for the marketing and not of any use besides that, some real benchmark numbers comparing the irr::array <-> std::vector:

Code: Select all

name             calls       time(sum)  
irr_empty_constr 100000      103             
std_empty_constr 100000      102             
irr_sized_constr 20000       105             
std_sized_constr 20000       131             
irr_copy_constr  20000       136             
std_copy_constr  20000       121             
irr_reallocate   10000       412             
std_reallocate   10000       8               
irr_push_back    100000      93              
std_push_back    100000      106             
irr_push_front   50000       1407            
std_push_front   50000       309             
irr_insert       50000       1496            
std_insert       50000       275             
irr_clear        100000      95              
std_clear        100000      87              
irr_set_used     5000        4               
std_set_used     5000        8               
irr_op_assign    5000        7679            
std_op_assign    5000        19              
irr_op_equal     50000       65              
std_op_equal     50000       80              
irr_op_unequal   50000       74              
std_op_unequal   50000       83              
irr_op_access    100000      98              
std_op_access    100000      86              
irr_get_last     100000      88              
std_get_last     100000      91              
irr_size         100000      89              
std_size         100000      79              
irr_alloc_size   100000      90              
std_alloc_size   100000      92              
irr_empty        100000      109             
std_empty        100000      84              
irr_sort         50          182             
std_sort         50          142             
irr_sort2        50          181             
std_sort_heap    50          169             
irr_search       10000       13              
std_search       10000       8               
irr_bin_search   100000      86              
std_bin_search   100000      84              
irr_lin_search   20000       23              
std_lin_search   20000       86              
irr_lrev_search  100000      91              
std_lrev_search  100000      112             
irr_erase        300         369             
std_erase        300         141             
irr_erase2       5000        182             
std_erase2       5000        98              

The sources can be found here: http://www.michaelzeilfelder.de/irrlich ... IrrStl.zip

Like all benchmarks, take the numbers with some grain of salt.
Unless the differences are huge they might be accidental.
Basically they are somewhat like I had expected - mostly similar, a few times each one is faster and in a few cases Irrlicht blows up (which we can probably correct without much trouble).

If you want to add some more classes for comparison - go ahead!
But it would be nice to tell me, so we don't do double work.
(edit: I will do lists, nearly there)

edit: Some hint I forgot - don't try to run it in debug. At least not if you need to do some more work on your computer the same day.
edit: *redface* I can't help it, but I get the feeling I'm partly responsible for the slowest parts in irr::array. Seems to me that might be caused by a certain bugfix: http://irrlicht.sourceforge.net/phpBB2/ ... hp?t=25534
Maybe STL does not call the copy-constructor for inserting (just guessing).

[agi_shi]

I think those statistics alone are good enough for most people to change their minds.

[MasterGod]

irr_op_assign 5000 7679
std_op_assign 5000 19

That's pretty amazing but I'm sure a quick glance at the source would reveal the reason quickly.

[CuteAlien]

I've updated the zip file with the tests once more. It runs now also on Linux (means simply that I added the 2 files to a Makefile...) and it profiles additionally the lists.

No big surprises for the lists. The assignment operator (list1 = list2) in Irrlicht is slow (around 400 to 20 ms), but the rest is mostly in the same range. I might play around a little more with profiling - I just had the idea tonight that I can also compare systems (like windows-linux) when I use a fixed array full of random numbers to have reproducable results over several runs. So I might add that. I'm also interested in doing some more tests with complexer testclasses as data and at least the strings and maps should also be tested. Though not sure yet if I find the time for it.

I have certainly to agree with MasterGod - once you know which part is slow you can improve it. Don't take the numbers too serious - they show some minor flaws, but speed really ain't so much of a problem (at least not for me). But maybe having the classes side-by-side is a first step towards writing an stl implementation of the baseclasses.

[agi_shi]

irr_op_assign 5000 7679
std_op_assign 5000 19

That's pretty amazing but I'm sure a quick glance at the source would reveal the reason quickly.

also @ CuteAlien:

I think you're both missing the point here. It doesn't matter whether a "quick look" at the source reveals the bug or not - there's too many places for "quick looks". The C++ standard library is already looked at, it's got all of this fixed for you, and it is guaranteed (in any full C++ compiler, of course, don't use VC++ 6 or something). It's really not about the "pride" of Irrlicht's own containers here, because, quite bluntly, they fall far behind the vigorously tested and used C++ STL; unfortunately, pride doesn't get you speed nor reliability.

Besides, something else hit me - why take time to maintain Irrlicht's containers (instead of just plainly using the STL), instead of take this possible time fixing up/adding to/polishing Irrlicht itself?

[MasterGod]

@agi_shi:
I've started this thread Because I think Irrlicht should be using STL so don't get me wrong, I'm all on your side about converting Irrlicht to STL.

[Dorth]

For now, unless Niko himself talks with the dev team and justify switching, I don,t think we'll see it happening. Maybe if there was a clearer majority of Irrlicht user wanting the switch too. But since none of those two situations are upon us, let's keep on working on a patch giving the choice to the user. It's a powerful first step that should satisfy all but the most extreme elements of the discussion. After that, there will always be time to dig in further. Btw, with proper inlining, we can make this patch nearly costless for the STL users...

[agi_shi]

@agi_shi:
I've started this thread Because I think Irrlicht should be using STL so don't get me wrong, I'm all on your side about converting Irrlicht to STL.

Oh, sorry, it's just the quote that threw me off

I'm only trying to point out the common sense here. Too many Irrlicht users seem to not want to switch just because of pride.

[CuteAlien]

also @ CuteAlien:

I think you're both missing the point here. It doesn't matter whether a "quick look" at the source reveals the bug or not - there's too many places for "quick looks". The C++ standard library is already looked at, it's got all of this fixed for you, and it is guaranteed (in any full C++ compiler, of course, don't use VC++ 6 or something). It's really not about the "pride" of Irrlicht's own containers here, because, quite bluntly, they fall far behind the vigorously tested and used C++ STL; unfortunately, pride doesn't get you speed nor reliability.

We're not missing your point. If you read the thread you will notice that this was already mentioned, though maybe with a little friendlier wording. We're all well aware of this. And I don't think it's much about pride, it's maybe a little about giving up control - something which c++ programmers never like to do (why would they programme c++ otherwise?). And certainly about all the other arguments which got mentioned by now.

Besides, something else hit me - why take time to maintain Irrlicht's containers (instead of just plainly using the STL), instead of take this possible time fixing up/adding to/polishing Irrlicht itself?

I guess switching containers would probably cost more time than the maintenance of the current classes for the next few years would cost. C++ refactoring is time consuming, so switching to STL is nothing you get for free :-(

It looks right now like the Irrlicht containers will stay and be used at least for some more time. And I can live with that at least as good as I live now with it :-) So why not improve them as much as possible?

[Dorth]

... Are people selectively blind or what?
The only dev answer we received stated why as far as they knew things were as they were, that they already discussed the topic, that a complete change was not possible right now amongst other things because Niko did not give his agreement, but that making a patch that use stl in the config in place of the containers already in place was a good compromise and would be instored if a decent one was proposed. Amongst others, I said I'd work my best to provide one. Others said it had already been done easily. What makes you think that "we" will keep using them as they are. The moment a patch is accepted and goes in, the STL for all we know might even be the default setting. Why don't people with an interest in this just concentrate on making this patch as best as possible, have it accepted and that way, this will be settled for now.

[MasterGod]

By the way Dorth, did you check 3Demon's implementation?

P.S
If there was a poll for which settings should be the default I'd vote for STL..