Urho vs stdlib Small Benchmark (VS2015)

Discussions General Discussion
#1

I wanted to do a quick test to see which containers perform faster.
Tried the two most common containers, vector and hash map.

The test was done with Windows 7 64bit, i5-2400 processor, Visual Studio 2015.
Urho3D version 1.4.

Code: (warning: quick and dirty)

Conclusions: (relative to what was tested)

  • std::vector is faster than Urho3D::Vector.
  • Urho3D::HashMap is faster than std::unordered_map.
  • std::string is faster than Urho3D::String.
Coding Guidelines
#2

For ints you should us PODVector instead of Vector

#3

Wouldn’t that be comparing apples to oranges?

btw would it be possible for Vector to do what PODVector does with template specialization and traits?
Maybe something like this (C++11): http://stackoverflow.com/questions/19154080/restricting-c-template-usage-to-pod-types

#4

We’ll still have to be a bit careful of C++11 only features. But for now, friesencr is right, PODVector should be used for ints for best performance. This can also be abused for non-POD types if the constructor/destructor don’t do anything vital.

#5

Why the need to be careful with C++11 ?

#6

On VS side that means upgrading to post-VS2010 versions, which can be argued to be more bloated than the previous, and don’t support compiling for old OS versions (there may be some niche use of Urho like using an old VS version such as 2008 to compile for Win2000 / XP)

Though I’ve been using VS2013 quite exclusively for some time and personally am happy with it.

#7

[quote=“cadaver”]On VS side that means upgrading to post-VS2010 versions, which can be argued to be more bloated than the previous, and don’t support compiling for old OS versions (there may be some niche use of Urho like using an old VS version such as 2008 to compile for Win2000 / XP)

Though I’ve been using VS2013 quite exclusively for some time and personally am happy with it.[/quote]

To me it seems like a huge sacrifice to hold back to be compatible with outdated software.
AFAIK VS2015 support at least down to win XP.

#8

You can also go the other way around and ask what are the absolute vital reasons/features (not just convenience) for the engine/library itself to go for c++11? Bear in mind, you can always choose to use c++11 in your application code.

If interested, here’s the c++11 discussion for Ogre: ogre3d.org/forums/viewtopic.php?f=4&t=80319

#9

I very much like that Urho3D is clean of C++11 constructs. Nothing is keeping me from using VS2015. We do have C++11 enabled for some ThirdParty libraries that use it very minimally. There are also compilers on various platforms that do not support C++11.

#10

[quote=“cadaver”]You can also go the other way around and ask what are the absolute vital reasons/features (not just convenience) for the engine/library itself to go for c++11? Bear in mind, you can always choose to use c++11 in your application code.

If interested, here’s the c++11 discussion for Ogre: ogre3d.org/forums/viewtopic.php?f=4&t=80319[/quote]

Looks like their reasoning is mainly based on ignorance and social proof. I also posted a reply there about the “auto is evil” nonsense.
Also the argument that C++'s stdlib somehow de-matured also doesn’t make sense.

While looking for reasons is important, “absolute vital” sounds like an attempt to invalidate any reason.
What are the “absolute vital” reasons for C++ over C? What are the ones of C over ASM?
The “absolutely vital” condition doesn’t make sense! Nothing is “absolutely vital” if you can get the job done. With that line of reasoning we’ll be still using punch cards.

C++11 have features that can make code shorter, easier to read and understand, easier to maintain, and faster. What else is there to ask for?
The discussion about C++ was started by how it can boost the performance of the most commonly used container by nearly 50%. (saying “use PODVector” is like saying “Use array” or something else with non-matching functionality)
Also VS2015 have great debugging tools: https://www.youtube.com/watch?v=NVCSuzFPzEM

The only reason so far is backward compatibility with outdated compilers. Even then, how do you draw the line for how backward compatible it is? C++98? C++85?
Of course that full backward compatibility doesn’t make any sense. A good heuristic is to be as advanced as possible while supporting the majority of the users.
Both vs2013 and vs2015 are backward compatible down to win XP. And I don’t think there are that many people who still use some 15+ years old version of windows.

Sorry about the rant, it’s just irrational to me and I had to let it out.

#11

I realize it’s a rant, but if we’re being serious, the difference between C & C++ is quite a large feature cutoff for large software such as Urho3D that could be considered “absolutely vital” for sanity, if not anything else.

Projects have to prioritize themselves differently, I can well understand if for some being modern in their language usage takes high priority. I believe the worst part of Urho not using C++11 is that project contributors don’t get to exercise their skills in the new language features.

#12

I hear the Magnum game engine author trip over new c++ feature bugs all the time. Often on exotic platforms. They are hard to detect sometimes.

I am a light contributor. I do not know c/c++ well. I believe also that the style that Urho is written in semantically represents the problem it is trying to solve well. As someone who does not know c++ well the more modest use of c++ features actually allows me to learn how to code better, faster. Through implementing my current project I have learned a great deal about pointer arithmetic and data.

#13

I think a game engine should be generic as possible and let the user handle anything more specific. SDL2 is one of Urho’s third-party libraries and it is written in C, it is used everywhere and it is extremely portable. But I am thumbs up for faster containers :slight_smile:

#14

The perf difference between a Vector and std vector is something worth investigating. Probably is related to the reallocation of strings when the vector’s storage expands.

#15

winXP - the best that has been created in Microsoft.
It is the working environment created by the developers.
win7-8-9-10 -… created by traders to make money. :wink:

#16

winXP - the best that has been created in Microsoft.
It is the working environment created by the developers.
win7-8-9-10 -… created by traders to make money. :wink:[/quote]
MS always was for profit business.
Win 7 is the best IMO.
Win 9 never existed, you missed the news :wink:

#17


But Microsoft has completed the official support Win7.
The next time Microsoft will say: DirextX 14 only for Windows 11.
Nothing personal. Only business. :wink:

#18

I like XP too, but new hardware is not working on it. :slight_smile: So I had to go to Win7.

#19

For this reason, I collected a computer
with the latest hardware resources that support WinXP.

Motherboard: ASRock z77 extreme4-M
CPU: Intel Core i7 - 3770T
DDR3 memory
Video: GeForce GTX 750Ti 2Gb
It good but hard to find motherboard with winXP support.

I use WinXP as a working environment.
For other platforms, have plans to use the remote method compilation
(using FTP connection) or duble bootable HDD.

#20

Hi,

I’ve learned a lot of C++ through Urho3D and prior to that Horde3D, as well as libraries often found in the VFX industry (OpenEXR/IlmBase). There’s so much to learn, but it’s fun to read up on this stuff.

I have on/off plans to make a plugin for Maya, and usually you need to match the compiler to the Maya version. So I’m a bit concerned that is C++11 really needed?
http://help.autodesk.com/view/MAYAUL/2016/ENU/?guid=__files_Setting_up_your_build_environment_htm
Visual Studio 2012 update 4, and this is the latest Maya! Older ones like Maya 2015 uses GCC 4.1.x for instance, it doesn’t say what it uses for Linux in this documentation. Recently the library OpenSubdiv reverted some C++11-isms to keep compatibility, for instance.

Not that it’s a problem for Urho3D to limit itself to a 3D DCC and I don’t want to force this requirement, but it’s kind of nice to not go with the latest and greatest. Sure there are ways around this like make a C99 wrapper and only interface to that to keep ABI compatibility. Actually does anyone know of a convenient library to assist in making one, and not by hand? Something akin to the GL/Horde3D API would be cool and would let you wrap it to any language too.

About containers, lots of hardcore game engine developers usually are huge fans of C99 for good reasons and just use constrained/minimal C++ features (templates/operator overloads/classes and minimal use of virtual functions in hot paths which is important to not cause pointer indirection which slows up in-order CPUs) and stay clear of the STD. For performance and fine-grained control reasons usually, like making explicit allocators for what you want to do without fragmentation, and for efficient cache use.
https://www.youtube.com/watch?v=rX0ItVEVjHc

I did find this the other day:
https://bitbucket.org/bitsquid/foundation
If you saw Autodesk’s announcement of Stingray, it’s actually the bitsquid engine…

Some good info too:
http://bitsquid.blogspot.com.au/