Incredible performace of Lua (luajit) over C++

[DarkRoku12]

I'm making a lua-sfml engine and i decide to test the performace making the same code on pure C++.

All compiler optimizations are on on both projects ( -O3 -fexpensive-optimizations ). (using codeblocks)

Not frame limit in both projects.

Lua-jit gets version  11 fps stable ( with  1000 crates on display , physics engine active ( there are 3 physics object active in the scene, some events dispatcher actives )

In C++ pure version got 8 fps stable ( with ONLY 1000 crates on the display..no physics engine active..no Lua states actives )

I use 2 counters for the test.. a custom counter on the game..and FRAPS.. both counter say the same fps rate. ( 11 for  lua / 8 for  c++ )

C++ code for the test only this no more:

#include <iostream>

using namespace std ;
#include <SFML/Graphics.hpp>
using namespace sf ;

int main()
{
    // create the window
    sf::RenderWindow window(sf::VideoMode(600, 600), "My window") ;
    int fps_rate = 0 ;
    Clock *fps = new Clock ;
    sf::Texture t ;
    // load the texture
    t.loadFromFile( "crate.png" ) ;
    t.setSmooth( true ) ;

    Sprite *obj = new Sprite[ 1000 ] ;
    for( int s = 0 ; s < 1000 ; ++s )
           obj[s].setTexture( t ) ;

    // run the program as long as the window is open
    while (window.isOpen())
    {
       
       // fps counter
        ++fps_rate ;
        if ( fps->getElapsedTime().asSeconds() >= 1 )
        {   fps->restart() ;
            cout << fps_rate << endl ;
            fps_rate = 0 ;
        }

        // check all the window's events that were triggered since the last iteration of the loop
        sf::Event event;
        while (window.pollEvent(event))
        {
            // "close requested" event: we close the window
            if (event.type == sf::Event::Closed)
                window.close();
        }

        // clear the window with black color
        window.clear(sf::Color::Black);

        // draw everything here...

        for( int i = 0 ; i < 1000 ; ++i )
        {
            window.draw( obj[ i ] ) ;
        }

        // end the current frame
        window.display();
    }

    return 0;
}
 

Screenshots:

lua version



The small crate and the long crates are physics objects. (the small crates is falling)
The bigs crates ( there are one thousand , you cant see it because are one behind other )
The console show the fps..and the yellow numbers are shown by FRAPS.

The same in the C++ version :



As you can see.. no physics..no lua States..

Please..if you can optimizate more this c++ code please post it for test it.

I would like yours reviews.

PD: link for the full images:

c++ : http://www.subirimagenes.com/imagedata.php?url=http://s2.subirimagenes.com/imagen/9376734c.png

lua : http://www.subirimagenes.com/imagedata.php?url=http://s2.subirimagenes.com/imagen/9376732luaversion.png

Lua game engine topic: http://en.sfml-dev.org/forums/index.php?topic=18074.0

[Jabberwocky]

Weird.
Are you running the C++ version from VisualStudio (or CodeBlocks it looks like)?  Even in release, that can be significantly slower.  If so, try running by double-clicking the executable instead.

[DarkRoku12]

Weird.
Are you running the C++ version from VisualStudio (or CodeBlocks it looks like)?  Even in release, that can be significantly slower.  If so, try running by double-clicking the executable instead.

Still the same for both.

[Nexus]

Incredible performace of Lua (luajit) over C++

Whenever I read such a sensational headline, I'm almost sure the measurement is distorted. There are JIT compilers that can outperform C++ in certain situations, but people who do so come with more analytic ways of presenting their results

Indeed, there are several issues with your C++ code, making the measurement meaningless:

• You should measure frame time, not FPS.
• Having a std::cout in the measurement slows down everything -- ah, I saw you're only doing it once a second, sorry.
• If you're really going for CPU performance and not just the GPU communication overhead, use fewer draw calls (sf::VertexArray instead of sf::Sprite).
  
• Use iterators or range-based for instead of index access. Make also sure that any debug checks in the STL are disabled.

And what's the point of

Clock *fps = new Clock;
Sprite *obj = new Sprite[ 1000 ] ;

when you can just use

Clock fps;
std::vector<Sprite> obj(1000);

without the need for manual memory management? Use RAII where possible.

[DarkRoku12]

There are several issues with your C++ code, making the measurement meaningless:

• You should measure frame time, not FPS.
• Having a std::cout in the measurement slows down everything, might as well be the bottleneck.
  
• If you're really going for CPU performance and not just the GPU communication overhead, use fewer draw calls (sf::VertexArray instead of sf::Sprite).
  
• Use iterators or range-based for instead of index access. Make also sure that any debug checks in the STL are disabled.

And what's the point of

Clock *fps = new Clock;
Sprite *obj = new Sprite[ 1000 ] ;

when you can just use

Clock fps;
std::vector<Sprite> obj(1000);

without the need for manual memory management? Use RAII where possible.

I replace all the code with the one that you give me.
Even i take off the fps counter and "cout" ..still the same..sometime ups to 10 fps (FRAPS) but then slow to 8 again.

i use memory management because i like C style.

[Nexus]

You're the one wanting to prove something, not me
I think it should not be difficult to apply my suggestions. And you're still measuring FPS, not frame time.

Where is the Lua code? How do we know it's equivalent?
A meaningful measurement would also include a minimum and average frame time aggregated over a longer time, not just random FPS sampled once a second.

Btw, I've also edited my post. Please avoid full quotes, it makes the thread hard to read.

i use memory management because i like C style.

If you have some time, you could read the RAII article I linked to, there are very good arguments against that

[DarkRoku12]

i use memory management because i like C style.

If you have some time, you could read the RAII article I linked to, there are very good arguments against that
[/quote]

For c++ it should be better using the tools provied the official libraries. But i still thinking the syntax is horrible.

I like a lot more C over C++ ( but sometimes i miss C++ features ).

But it i like C over C++ for this.
1) Is a lot more portable.
2) Less API it have..less you need to know.
3) Its faster ( OpenGL is faster that DirectX ) ( chipmunk-physics are faster than Box2d) ( I use box2d because have a better API and documentation ).

I will see carefully of RAII , looks ougly but great for the memory leaks.

[Nexus]

I like a lot more C over C++.

Nice, but you're making a C++ comparison here. Personal preferences should not affect an objective and expressive benchmark

3) Its faster ( OpenGL is faster that DirectX ) ( chipmunk-physics are faster than Box2d)

Sorry, but this is complete bullshit, especially with those examples. It's so fundamentally wrong I don't even know where to start. But you'll find these kinds of arguments all over the internet, there's no need to repeat them here... So I'd say we concentrate on the benchmark in this thread, no need for another C vs C++ flamewar.

I will see carefully of RAII , looks ougly but great for the memory leaks.

You should really read my article. Exactly this kind of unfunded myths are refuted.

To be honest, you're just giving me more and more the impression that you don't really know what you're talking about. No offense, but when you're trying to prove something (especially speed), you should be familiar with the programming language and measuring techniques -- or at least willing to incorporate improvement suggestions, rather than sticking to dogmas you've heard somewhere and never questioned.

We're still missing the Lua code, by the way

[DarkRoku12]

3) Its faster ( OpenGL is faster that DirectX ) ( chipmunk-physics are faster than Box2d)

Sorry, but this is complete bullshit, especially with those examples. It's so fundamentally wrong I don't even know where to start. But you'll find these kinds of arguments all over the internet, there's no need to repeat them here... So I'd say we concentrate on the benchmark in this thread, no need for another C vs C++ flamewar.

I will see carefully of RAII , looks ougly but great for the memory leaks.

You should really read my article. Exactly this kind of unfunded myths are refuted.

I know that Lua is slower than C++ . When i made the first test i thought  "C++ sure achieve 20 fps or more"..but not.

Luajit is a good tool too, speed up the lua code. ( I'm traying to make the engine comatible with lua 5.2 ...is a headache cause the incompatibilities but it's possible. )

I can post the lua Code.. but there is a lot of libs ( .hpp / .lua ) involved , i can't post all. When i release my engine all will be on github.

You really want to see all the code ? ( i can upload it now if you want )

[Nexus]

The problem is, without code your benchmark doesn't really express anything (we don't know exactly what you did and how you did it). Furthermore, it can't be repeated by others. In short, it's no proof.

But you don't need to publish all files now, you can also wait until your engine is finished, when it's easier to put the benchmark together

[DarkRoku12]

The problem is, without code your benchmark doesn't really express anything (we don't know exactly what you did and how you did it). Furthermore, it can't be repeated by others. In short, it's no proof.

But you don't need to publish all files now, you can also wait until your engine is finished, when it's easier to put the benchmark together

Great, i have implemented RAII in the past..but i have a obsessed to know ALL , how it's work, why?, why it was created? I learn some assembly for understand better the low-levels concepts. But more deeper you get in C++ more you have too learn and it's difficult to see all the source files of c++, things that i do because i like programming. But i have social live too..   

[Tank]

JIT-compiled programs are known for having optimized execution paths, and thus perform better -- often, not always. We really need the source of both test cases in order to reproduce your performance claims.

What did you use to build the C++ benchmark? Tried Clang?

[DarkRoku12]

What did you use to build the C++ benchmark? Tried Clang?

No ,i haven't tried.
Is better than GCC ? .

I use the GCC alongside code::blocks ( its the 4.7.1 i think ) , i also use the SFML 2.2 ( SJLJ ) version if my memory don't fail.

But in both case the rendering work is done by the c++ , lua only store the pointers and then pass it to the main loop for the rendering/drawing.

In my engine the "hard" and "dirty" part is done by c++,  lua give c++ the pointers and c++ give the events from the pollevent to lua, and then lua handle it.

[Grimshaw]

Doubt this comparison is fair.. as Nexus said, there are many variables to take into account when making a fair test of runtime speed, so I doubt this one is not distorted..

Though, I have heard really good things about luajit, so I am sure it is really fast nevertheless, given that even the lua default vm is quite efficient.

[Klaim]

Well if fraps tells you that you got low fps, it's certainly that there is a problem with your gpu-side work. In particular when you're doing nothing else than display.
Which means it have nothing to do with C++ or lua....