Eu To C Translator: An Inmate's Review
Well I saw my long awaited return whent unnoticed
because my 'too personal' post was moderated-out, so
I'll make it short.
Whent to jail, got out, am here.
Now, I talked to Rob about Euphoria's future, and as I
see I started people thinking about Eu's future on
non-x86 platforms (as the recent threads prove), I
have the good news that Euphoria will be Portable in
the future, for a price, but like I was here to
advocate such a portable Euphoria to Robert, I'm also
here to make sure the product which he produced under
because of my constant nagging :p sells.
So, people, do pay for a portable Euphoria, or i'll
kick you in the back (J/K) :p
Euphoria To C seems to have improved incode production
volume-wise, but quality-wise (ie. speed) it's still
lagging.
Therefore I'll state the following (again) to ensure
Rob takes nottice of the situation;
- The future Portable Euphoria should still come as 2
packages, one for E2C and one for the interpreter. Rob
made it clear to me that the interpreter and
translator share one codebase, so if he ships the
translator source, he's shipping the interpreter
source, and vice versa.
I'm sure parts of the C code are put in an #ifdef
clausule so that Rob can state: #define TRANSLATOR to
get a translator compilation from the shared codebase.
Hence if the translator's ec.lib source code is
released, giving all exported routines new function
bodies for a new platform will actually make your Eu
program run for that new platform.
Recently I got my first C compiler for the new GameBoy
Advance console, and I'd like to see myself coding
demos and apps in Eu for it in the future. Garbage
Collection on such a mini-RAM system is mandatory, and
Eu's is excellent.
- Things like atom/sequence math in the E2C produced
source (binary_op*();) should be Macros, not
functions.
Who'd call a damned function just to do '1+1'? That's
just waaaay too slow.
The calling overhead is just to much, math is done
millions of times per second in a complex computer
program, that's millions of functions to call while it
should just be millions of math machinecodes to
execute.
Any 3D graphics application in Euphoria will be 100 to
1000 times slower compared to C JUST due to this! I've
had it happen to me while coding an app in C and Eu
simultaneusly, and later when reviewing the C code
produced by ECW.exe found the cause of the lag in my
3D code, binary_op() being called 640*480*100 times
pers second *just* to perpective project my voxel
landscape. Same thing for rotating the camera, when
hundreds of thousands of voxels have to be rotated
every frame, that's 6 calls to binary_op() per voxel!
That's just insanity!
While all the hand-written C version does is six math
operations, like + and *! That's compiled to ADD-MOV
and MUL-MOV! Instead of (with E2C)
PUSH-PUSH-CALL-ADD-MOV-RET-POP-POP, in the best case
since I don't know what binary_op()'s body looks like
(but it'll be more than just one math instruction in
any realistic scenario).
So, INLINE Rob!
Save the calling overhead!
6 times faster speeds is a mathematically correct
prediction!
If you don't like the memory overhead produced,
atleast use a label instead of a function in the C
source, that's just a jmp instruction to call it (and
use two globals for the parameters to pass).
- de_reference() is still called too many times,
inline it!!
Or, again, atleast make it a labeled goto!
- Doing BOTH of the above (requiring 15 minutes of
work for Rob!), will increase overall program
execution speeds with about 700% for programs using
reasonable amounts of math and atleast one variable
being used in a loop.
Mike The Spike
|
Not Categorized, Please Help
|
|
