Re: Muhahahaha

new topic     » goto parent     » topic index » view thread      » older message » newer message

On Fri, 11 Aug 2000 01:45:15 -0600 Admiral Deah <deah at HOME.COM> wrote:
>> void doit(int val)
>> {
>>  int i;
>>  int v;
>>  for(i = 0; i < 50000000; i++)
>>      v = val;
>> }
>
>In any good compiler (VC++ included), the function doit will be optimised to
>this:
>
>void doit(int val) { }
>
>Why? First the optimiser will unroll the loop (since it is a fixed number of
>iterations), and determine that the 'v=val' assignment has been made
>redundantly, and eliminate 49999999 assignments. Then, since there's no
>loop, 'i' is not needed. finally we just have a 'v=val' function, which
>doesn't return anything, so again, this will get optimised out of existence.
>Finally, during the dead code elimination cycle, the doit() function calls
>will be eliminated completely. Thus you're timing the delay between two
>puts() statements, which really shouldn't be a long time. Try it again, but
>change the function doit to something like this:
>
>int doit(int val) {
>    int i, n, v;
>
>    // this is how many times we'll loop
>    n=val*1000000
>
>    // the loop is now a variable, so it's nature
>    // is unpredictable, and unrollable
>    for(i=0; i<n ; i++)
>
>        // the inner function can't do the same thing, it
>        // has to be iterative, or it will get moved out of the
>        // loop
>        v+=i;
>
>    // we need to return a value, or the function is useless
>    // and may still be optimised out of existence
>    return v
>}

Not exactly. I compiled my code and found there to be a timespan between the two
puts, therefore proving (to me) that the loop actually did run.

>And by the way, DirectX does all the time-consuming vertex transformations,
>clipping, etc, and would not be the responsibility of Euphoria. I believe
>the same is true in OpenGL, so your last statement is irrelevant. While the
>interpreter's speed is important for a game, the rendering speed is far more
>important. And in this case would be quite independent of the interpreter's
>speed. Euphoria is fast, and I dare you to test this (and maybe some
>other's, I don't have a C++ compiler installed right now), with timer()
>added to show the actual speed difference. (Actually, this may cause an
>overrun, I'm not sure, perhaps a better test would use floats?)
>
>PS: Recommend reading the "Lava" by Irv Mullins as well

So you state that because Euphoria is so slow, in a video game it needs to have
a C++ program (Direct X) to do the hard work? Even so, Euphoria does not even
support DirectX!
DirectX consists of COM (ActiveX) controls, and Euphoria can not make use of
them directly. The only way Euphoria can call DirectX functions, is by going
through a slow layer of Euphoria Program -> Interpretter -> Exotica -> DirectX
while with C/C++ programs it's just Program -> DirectX. Not to mention that
Euphoria's function calling speed is very slow compared to C or C++'s, thus
meaning that everytime you call upon a Direct X routine to actually render a DX
scene, you are losing frames per second.
AND, if that weren't enough, DirectX most certainly does not do vertex
calculations for you!! Yes there was a time when DirectX had a component called
Direct 3D Retained Mode, a lacking and slow component wich did the vertex
calculations for you, but that component has being stripped out by Microsoft and
they didn't support it anymore after DirectX 6. The only part of Direct X that
involves vertex calcuations, is Direct 3D Immediate Mode today, and it does not
do the calculations for you (otherwise you'd have Retained Mode, see?). So in the
end, all your Matrices wich you pass onto Direct X/3D through Euphoria are going
to be slow, dynamically allocated and garbage collected "sequences", and adding
that to above function calling overhead, I'm happy to say a Euphoria game will
run at half the speed of a C/C++ game in FPS, if not at a tenth of the speed.
(60fps become 6fps!!).
OpenGL requires you to do your own Matrix and vertex handling, thus falling in
the same basket as Direct X. Plus, there exists no Direct X for Linux or DOS,
thus you can't rely on DX anyways, and yet while there is OpenGL for Linux and
DOS for C/C++ programs, Euphoria programs can not use them to this date.




*********************************************
Want free email? Sign up at http://www.freeze.com !

new topic     » goto parent     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu