1. 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
2. Re: Eu To C Translator: An Inmate's Review
On 26 Jul 2001, at 10:37, mtsreborn_again at yahoo.com wrote:
<snippage engaged, but not documented>
> 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
Altho Eu may have a priority in my existance, so does food. Some of us pay
for only what we need at the time we need it, that's all we can do.
> - The future Portable Euphoria should still come as 2
> packages, one for E2C and one for the interpreter.
I agree, there could easily be two paths of code here, due to optomising in
the E2C translator. The reason i say this is the possibility of calling
functions
in the interpreter directly in the future, and the interpreter needing to
enforce
types/bounds in each and every function, whereas this overhead could be
skipped or if-else'd-out in the translator for speed and the assumption the
programmer knows what they are doing, or at least proofed the code using
the interpreter first.
> Or, again, atleast make it a labeled goto!
OOOOOOOOHHHH, that dreaded 4-letter word again!! hehe! 
> - 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.
For graphics, yeas. I think Eu is going places Rob hadn't considered when
he began this language. I still don't do graphics, altho i have considered a
great little 3D app, and i could still use a .jpg/.gif overlayer/manipulator
program in a certain http proxy application. I still dream occasionally of a
dedicated strings handler hardware box, which uses little math compared to
those, but still uses a mess of memory and does an equally large of garbage
collection.
Kat
