About compilers and code execution times

by Dimi 28. March 2008 01:44

I took some time to make some tests with compiler optimizations and while trying some settings and triggers I thought it would be interesting to profile the execution times of compiled code to see what the compilers really do.

Tools I used:

  • Paul Jackson's in-game-profiling library in C++
  • Dev-Cpp using MinGW v3.4.2
  • Visual C++ 2008 Express Edition

 

The following class was created:

   1: class ClassProfile   
   2: {   
   3: private:   
   4:     float x;   
   5:     float y;   
   6:     char szText[255];   
   7: public:   
   8:     ClassProfile();   
   9:     ~ClassProfile(void);  
  10:     
  11:     void    ExecDoLoop();  
  12:     void    ExecForLoop();  
  13: };

Listing 1

 

The following calls were made:

   1: ClassProfile m_Class;
   2: ClassProfile* m_pClass;
   3:  
   4: dev_ProfileBegin("ExecForLoop_obj_Outer" );
   5: m_Class.ExecForLoop();
   6: dev_ProfileEnd("ExecForLoop_obj_Outer");
   7:  
   8: m_pClass = new ClassProfile();   
   9: dev_ProfileBegin("ExecForLoop_pointer_Outer" );      
  10: m_pClass->ExecForLoop();  
  11: dev_ProfileEnd("ExecForLoop_pointer_Outer");
  12:  
  13: delete m_pClass;

Listing 2 

 

The testdrive

The function ExecForLoop consists of two cascaded for loops which perform some basic arithmetic operations. The three candidates are Dev-Cpp vs Visual C++ 6.0 vs Visual C++ 2008 Express Edition. In all the three IDE's an empty console application was created. A release version was compiled. The compiled version does not include compiler optimizations but was compiled using default settings.

 

Results in direct comparison:

Version Visual C++ 6.0 Visual C++ 2008 Dev-Cpp
  min max avg min max avg min max avg
ExecForLoop_obj_Outer (10 cycle) 0.1 0.1 0.1 15.1 15.1 15.1 0.1 0.1 0.1
ExecForLoop_obj_Inner (25000 cycles) 50.7 50.8 50.8 24.4 24.4 24.4 50.8 50.9 50.8
ExecForLoop_pointer_Outer (10 cycles) 0.2 0.2 0.2 30.6 30.6 30.6 0.1 0.1 0.1
ExecForLoop_pointer_Inner (25000 cycles) 49.3 49.4 49.3 26.6 26.6 26.6 48.7 48.7 48.7

 

What we see is that creating objects on the stack, the code execution time of VC++ 2008 is unbeatable with incredible 24.4 ms. VC++ 6.0 and Dev-Cpp runs equal with about 50.8 ms. But take also a look on the outer loop. Wow 15.1 ms for the VC++ 2008 but only 0.1 ms for VC++ 6.0 and Dev-Cpp either. Why that? To explain this you should have a basic understanding of the memories available on your machine and also compilers. The .NET framework has an incredible memory handler and so the compiler handles the code. While loosing some ms on the outer loop the inner loop with the time critical path takes half the time of the other compilers. Cool isn't it?

Now let's take also a look on our object that is created on the heap. What is the advantage of the heap? The heap provides you nearly endless memory (only limited by your hardware) but is slower than the memory on the stack but we see that all applications are faster on the heap than on the stack. So how can happen this? Quite easy. The allocation for the memory on the heap and the object creation is done only once with the line 8 in listing 2. The memory is already reserved for the function and so it can be executed as often as possible, it will always be fast since the functions calls the entry point in memory where everything is already stored. If we would create the object dynamic within a loop it would take much longer because the allocation handling and accessing is what makes the heap slower than the stack. The difference between VC++ 6.0 and Dev-Cpp is very marginal, again VC++ 9.0 is the winner.

 

Also interesting is the file size. 

Version Visual C++ 6.0 Visual C++ 2008 Dev-Cpp
File size 73,728 bytes 10,240 bytes 1,743,880 bytes

 

What do we learn from this table? Nothing we didn't already know but let's go more into detail. The smallest file was produced from the Visual C++ 2008 with about 10 Kbytes followed by Visual C++ 6.0 with 72 Kbytes and on third and last place with over 1.66 Mbytes comes the Dev-Cpp version.

Why are there such great differences? Let's start with the two extremes VC++ 2008 and Dev-Cpp. VC++ 2008 has such a small file size because it uses the .NET framework. That means that you need a framework installed which's download size varies between 22 - 195 Mbyte. The compiler simply stores the most necessary into the application, everything else (memory tables etc) is called from the framework. Dev-Cpp instead has a file size of 1.66 MByte because MinGW links from static libraries as much as possible. So a minimum on additional dll's and runtime environment is required but that increases file size of the application.

In other words you could run the Dev-Cpp console application on a new installed machine without having to install any other runtime or framework. You would have to install the Microsoft Visual C++ 2005 Redistributable Package to run the VC++ 6.0 application and you would even have to install the .NET framework to run the VC++ 2008.

I want to point out that all the three compiled release versions have been compiled without any compiler optimizations. I also want to point out that I used Visual C++ 2008 Express Edition with the .NET framework 3.5. As you know the Visual C++ 2008 Professional Edition provides an optimized compiler and could produce better code quality which would top the already great timings of above.

 

Didn't we forget something?

No I didn't (the first)!!! Borland fans will complain why I didn't refer to the Borland C++ Builder. Two reasons for that. First is that I didn't want to go through all the registration process on their website to register for a trial of their latest product Borland C++ Builder 2007 and I couldn't find my old CD with Borland C++ Builder 5. The second reason is that Borland doesn't provide a free version of this. This article is for those of you who don't want to buy a compiler for 900 $ when you are able to download one for free.

No I didn't (the second)!!! LCC IS NOT a C++ compiler. Although this is a great project (and I'm using this too) it's a C compiler and not a C++ compiler which makes it for me uninteresting. Don't get me wrong. I like lcc but I'm more the OOP guy.

 

Conclusion

I love Dev-Cpp and work as often as possible with this tool. Not only you learn to develop with C++ the ANSII "way" but it's free and uses, with MinGW, a very powerful compiler. It doesn't need any runtime or framework to run (when using standard functions). I learned to love Visual C++ 2008 and try to go more into deep with this tool. Microsoft offers a really cool IDE with, as we can see above, a really powerful compiler which produces good and fast code and all this for free. This is an important thing (especially when we thing of the endless discussions in bb's how bad Micro$oft really is... blablabla) when thinking to develop for private use.

Try it for yourself. All you need can be found below in the link section and you need the function timeGetTime() or a timer written in Assembler if you need a more accurate timing method ;)

 

Links

  • Microsoft Visual C++ 2008 Express Edition can be downloaded here
  • Dev-Cpp 4.9.9.2 with MinGW 3.4.2 can be downloaded here

Tags: , , , , ,

game development

The future of the DirectX.DevPak for Dev-Cpp

by Dimi 23. March 2008 22:46

gproductions2 June 22nd 2004 the website G-Productions was launched. This site was dedicated to my very own afford to create a game engine using DirectX. I was not a friend of the Visual Studio that time since I could not afford this (it was not that cheap that time), so an alternative compiler had to be found. Soon I stepped over Dev-Cpp. This was a very complete and full functional IDE which uses the MinGW compiler. Cool was my first thought, but the first problems were soon knocking on the door. Those of you who ever tried to use DirectX with the MinGW compiler know what I'm talking about. A bunch of compiler errors say hello if you include a DirectX header file.

Teaching a compiler the Microsoft way

DirectX_75x65 Searching the www I could not find any way how to use the DirectX SDK with the MinGW compiler. A DirectX DevPak was available but it included only the DirectX Graphics component of SDK and it was not very complete (imagine the D3DX functions library). On several forums and bb's people already had posted problems with using MinGW and DirectX SDK (that time people referred to the DX SDK 8.1). Soon I realized that there was the need of an adequate solution. Download the DX SDK and let's get to work I thought and so I did. After downloading the DirectX SDK 9.0 I started reading through the compiler tools documentation. After a short time I got all the DirectX Graphics issues fixed and I had a stable release of the graphics library of the SDK. Most important thing was, that it was full usable and full functional with Dev-Cpp.

Next step: DirectInput

Next task on my list was the DirectInput library. Some fixes here some fixes there and converting the library and here you are with a complete DirectInput library for MinGW. Easy I thought, let's get to the sound stuff.

The audience is listening

That time for audio the DX SDK provided the DirectSound and DirectMusic library. While DirectMusic was easy to convert, DirectSound made some problems because of the use of some defines which were not so easy to work with.

DirectShow

The biggest problem when working with the MinGW compiler tools is also the best feature. The MinGW compiler is an ANSII compliant compiler and allows only ANSII compliant C++. The complete DX SDK contains partial non-ANSII-compliant code. That was the issue most people complaint about. Within the DXSDK a script language (IDL) was used what was also difficult to change that MinGW could work with it. Most work with the DXSDK was changing some parts of the header files, mainly fixing scoping problems and/or rewriting the IDL parts and the header files worked very well with MinGW. But what I faced with the DirectShow part was terrible. Let's say I needed one month of work to make DirectX Graphics, DirectSound, DirectMusic, DirectInput and DirectPlay work with MinGW I needed at least 3 more months to convert the DirectShow stuff. My intention was to release the most complete DirectX.DevPak available so people could use it for their applications. My intention was also that my DevPak should compile out-of-the-box. So I didn't loose a word on my DevPak until the DirectShow part was also converted. The problem was that most tutorials and samples used the BaseClasses, a static library which wrapped many things up and allowed the developer to render videos on textures or for DirectDraw on surfaces. These BaseClasses library was nearly impossible to change for MinGW. Finally with some tweaks DirectShow was usable with MinGW and I included the samples and provided it for download.

Past and future

Four years I spent more time on keeping updated this DirectX.DevPak, which was originally designed to help me and my team developing the blueEngine, than on working on my own game engine (Microsoft loved me so much that they began releasing a monthly update on the DX 9.0 SDK). The DirectX.DevPak became an own single project that took most of my time.

Since the release of the Visual Studio Express Editions especially the XNA Express version I began asking myself if it would make any sense of continue the work on the DevPak and release any further updates. The reason why I started to work with Dev-Cpp and the MinGW compiler was that I didn't have the money to buy a Visual Studio C++ 6.0 version. Now Microsoft introduced the Visual Studio Express editions giving such a great development environment away for free. Why should someone still need an updated DirectX.DevPak? I downloaded the DirectX SDK March 2008 and tried to look how much work it would be to convert it. So many changes, monthly updates, some functions were dropped others were introduced...

 

There definitely won't be be any more updates on the DirectX.DevPak. The last release is available here. The changes on the DXSDK are too many. I would have to convert the complete DXSDK March 2008 and I simply don't have the time for this. It was great to work on this DevPak you can learn so much about C++ when having to work with compiler and linker issues, different static library formats. I think this also improved the way I'm programming in C++ and of course influenced the way I think about open-source projects a standardized static and dynamic library format etc.

 

DirectX.DevPak versions here available

Download the DevPak here

 

Tags: , , , ,

DevPak

blueEngine – a DirectX game engine

by Dimi 9. April 2005 12:58

About
The blueEngine is a high scalable and high performant game engine. It includes several modules such as support for sound, its own scripting engine and a network module. The blueEngine uses the DirectX 9.0 API and was fully developed with the MinGW compiler. Since the engine is still under development we won't follow the regular way and provide this engine as open-source but work on it as a base for some upcoming games in the pipe.
Features
Features Render-Interface:

  • BSP level rendering (PVS, frustum-culling)
  • octree rendering
  • shader model 2_0 and 3_0 support (native shaders and HLSL)
  • shadow volume rendering for real-time shadows
  • static models (LOD) supporting the formats MS X-File, 3DS, ASE
  • skinned mesh (skeletal animation) supporting the formats MS X-File, Cal3D
  • terrain rendering (LOD)

Features Audio-Interface:

  • 3D sound output
  • supporting WAVE, OGG and MP3 files

Features network-module:

  • client-server architecture

Features physics-engine:

  • ragdoll for Cal3D und X-File skinned mesh
  • full-scene collision for all scene objects like level and models

Features script-engine:

  • supporting XML, Lua and an own script file format
  • full integration of all components

planned features:

  • KI. Already designed a concept for path finding in bsp-trees

Additional information
The blueEngine uses the following 3rd party software or tools.

  • Dev-Cpp
  • Newton game dynamics
  • ogg vorbis sdk (MinGW version available here)
  • Direct90.DevPak (MinGW version available here)
  • Doxygen source code documentation

Q: What is the blueEngine?
A: The blueEngine is a high scalable, high perfromant game engine. It's written in C++ using the DirectX graphic api.
Q: Is the engine available for public use?
A: No, at current the blueEngine will only be used here at G-Productions and will be made available to partners of G-Productions. There are plans to publish a light version of the blueEngine for public use.
Q: It's a 3D engine right?
A: No. It's a game engine. The difference to a 3d engine is that the blueEngine consists of a render device, an audio device, a network module and a script engine. A 3d engine instead consists only of a render device for graphics.
Q: Why another game engine?
A: There are a couple of great graphic engines free available on the internet but nothing that meet our needs. So we developed our own.
Q: Is the blueEngine in any way related to the blueTec engine?
A: No not at all. The blueTec engine is a 2d graphic game engine with a basic audio module for people with less knowledge in programming to quickly getting results. The blueEngine is an up-to-date game engine competitive with many free available game engines out there.

Latest screenshots
These screenshots where made using specular highlight (shader model 2_0) and per pixel light

1-screen00 1-screen01 1-screen02 1-screen03 1-screen04 1-screen05 1-screen06

Tags: , , ,

game development

OggVorbis win32 DevPak for Dev-Cpp

by Dimi 26. June 2004 13:16

About the OggVorbis sound library
The OggVorbis sound library is one of the greatest sound libraries available on the net.
The advantages of OggVorbis are the same like those of the mp3 format.

  • sound compression with (nearly) no loss of quality.
  • easy to use and implement in applications
  • SDK available
and the most important which makes OggVorbis our favorite sound library: it's free. No royalties.
The last point is maybe the most important. While implementing mp3 sound in your applications means the payment of royalties to the Frauenhofer Institute in Germany, you can use OggVorbis for free. The SDK contains everything a developer dreams of.
Why not use other sound libraries like fmod or bass?
Sure the fmod library is a really great and advanced sound library and provides really everything for developers. It's implementation is easy and its usage is great, but the disadvantage is, that you have to provide the dynamic link library with your application in order to use this. Now imagine you are developing a game or a game engine :-) and your design already includes enough libraries. Why not implementing the sound in one of your own without the need of an additional dll?
Why releasing a package
With installing the SDK you are ready to go for developing, as long as you use Microsoft Visual C++. If you want to use the OggVorbis SDK with MinGW you have to rebuild the libraries to readable format for the MinGW compiler. It was kind of work get this done, so we thought of providing this devpak to the public and below a step-by-step instruction on how to compile the OggVorbis stuff yourself.
What the DevPak contains
  • the dynamic link libraries
  • the documents provided from the original OggVorbis SDK
  • the example code from the original OggVorbis SDK
  • the header files in their appropriate folders
  • the static libraries
For a detailed description what will be copied on your system, refer to the readme file included with the devpak.

What the SDK contains
The OggVorbis SDK contains the necessary header files for using the sound library and it contains the static and dynamic libraries. The static libs are divided in two parts. The first part includes all the libraries necessary to link to the dll's the second part includes all libs for linking the sound stuff into your application. These libraries are specified with the word static which is included in the lib name before the extension. Example: ogg_static.lib If we take a closer look at these libraries we will recognize, that these libraries are not readable from the MinGW linker. They are for Visual C++ only, so we have to build these libraries manually. The good thing is, that you can use the libraries for dll linking since they are readable. That means that if you are going to use the dll's provided with the SDK you don't need to do the steps below. That also means, that you have to include the dll's with your application and that is not the way we want to go on. So let's build the libraries ourselves.
What do we need?
What we need is:
  • the libogg source. Download the file libogg-1.1.zip at OggVorbis homepage
  • the libvorbis source. Download the file libvorbis-1.0.1.zip at the same location as above.
  • the MSYS package. Download the package at the MinGW site
  • a modified version of the os_types.h header file which can be downloaded here

The first step
..is to install MSYS. This is a great collection of tools for MinGW and makes life easier.
After installing MSYS (by the way, MSYS stands for Minimal SYStem) unzip the libogg-1.1.zip and the libvorbis source on your harddisk (I would recommend you to unzip them in separate folders).
Now replace the file {MyDrive}:{MyFolder}libogg-1.1includeoggos_types.h with the new header file you downloaded at the above location. If you aren't able to find the location of the file on your hard disk replace {MyDrive}:{MyFolder} with the drive and folder name you unzipped the SDK.
Now we are ready to go. Start the MSYS console with a double click on the icon on your desktop and switch to the root folder of the libogg SDK. The console prompt is UNIX like so some of you may have problems at first but believe me it's easy and similar to DOS. Once you are in the root folder of your libogg SDK type the following into the console prompt:
$ configure --disable-shared
Now MSYS will do all the work for us, like checking the compiler version, running some tests etc...
When MSYS finished creating the makefiles we need type the following into the console prompt:
$ make
This will build at least the desired libraries we need. Watch the console output. If you followed the steps above no error should occur. Otherwise check if you really followed the steps above and use the recommended versions of the tools and packages we mentioned. Now the first step finished. Now we have to build the vorbis libraries.
The second step
Copy the ogg folder of your libogg-1.1include folder into your MinGW include folder. Go to your src.libs folder and copy the file libogg.a into your MinGW lib folder. NOTE: the library can directly be copied to the lib folder of your MinGW installation but you have to copy the complete folder ogg of your Include folder into your MinGW include folder. Switch on the MSYS console into your libvorbis-1.0.1 root folder. Type the following into your MSYS console prompt:
$ configure --disable-shared
Now MSYS will work again and build the makefiles for the vorbis SDK. If the console output reports an error, you most probably didn't copy the ogg folder of your libogg-1.1include folder into your MinGW include folder. After finishing the makefiles and dependencies type the following into the MSYS console prompt:
$ make
Now the vorbis libraries are compiled. After finishing the compile process you should have a new directory within your libvorbis-1.0.1lib folder named .libs Switch into this directory and here you are the last libraries. Now let's check if we did everything right.
In your libogg-1.1src.libs folder should be the following files:
  • libogg.a
  • libogg.la
  • libogg.lai

In your libvorbis-1.0.1lib.libs folder should be the following files:
  • libvorbis.a
  • libvorbis.la
  • libvorbis.lai
  • libvorbisenc.a
  • libvorbisenc.la
  • libvorbisenc.lai
  • libvorbisfile.a
  • libvorbisfile.la
  • libvorbisfile.lai

Congratulations, you have build all the static libraries to use the complete OggVorbis sound library with your application. Copy all the *.a files into your MinGW lib folder
Copy the folder:
- libogg-1.1include
- libvorbis-1.0.1include
into your MinGW include folder. You're done. Happy programming. If you encountered any errors or are not able to compile after following the above steps, just mail us or head over to the forums. If you are too lazy to do the steps again download the compiled libraries from here.

OggVorbis-win32sdk.DevPak (2,09 mb)

Tags: , , , ,

game development | DevPak

DirectX.DevPak for Dev-Cpp

by Dimi 26. June 2004 13:01

Here you are with a DevPak designed for Dev-C++.
This package was build in order to make it easier for you to use DirectX with the MinGW Compiler used in Dev-C++ . A lot of work was done on this package but the results show that it was worth the work As far as we know, it is the most complete DevPak for DirectX available.
The package:
When we started looking for a package we used the distribution of Gorobei and Zero Valintine from www.gamedev.net. Soon we noticed that it was just a build of original DirectX SDK files, not optimized to work completely with the MinGW compiler. After some basic changes on the DirectSound and DirectMusic stuff we got the most modules working. The last big challenge was the DirectShow part of DirectX. Picked with many IDL interfaces maybe this was the most difficult part of the complete package. After getting this to work and after re-building the BaseClasses (Kudos to ToTo who did the most work on this) the final step was done. We added the mmreg.h (for some multimedia registration stuff) to complete the package and provide it to you as is. Work is not finished yet. We continue improving the package to make it the most complete DirectX.DevPak available, so it will (hopefully) be one day a 1:1 copy of the DirectX SDK.
The DevPak includes:

  • all header files of the DXSDK (MinGW compatible)
  • all libraries of the DXSDK (MinGW compatible)
  • some debug and helper libraries (shared dll) of the DXSDK
  • some templates to create dx projects within Dev-Cpp from scratch.
  • DirectX icon
  • the helper classes of the DXSDK


Note:
You don't really need the DirectX9 SDK. What you have to install is the DirectX 9.0 runtime version. You should also be carefull not to have installed the DirectX.DevPak available through the update module of Dev-Cpp. In some cases you might get compiler errors, caused by concurrent versions.
More information:
For more help on DirectX9.DevPak visit our message board. For more information on Dev-C++ visit: the Bloodshed forum
Credits:

  • ToTo for contributing some major changes on the libraries and for help on the BaseClasses
  • EvilInvader for all that ml-shit I couldn't get rid of.
  • NinjaNL for using the DevPak and providing us some usefull information on usage and testing.
  • Yeoh for the How_to_make_Devpaks.txt at http://www.yeohhs.com

DirectX9_help.rar (11,42 mb)

DirectX90.DevPak (3,63 mb)

DirectX90b.DevPak (5,07 mb)

DirectX90c.DevPak (6,23 mb)

Tags: , , , ,

DevPak | game development

Powered by BlogEngine.NET 1.6.1.0
Theme adopted by Dimi with portions of Mads Kristensen and portions of Rtur.net

RecentPosts