OpenEuphoria

Re: Translator Runtime Checking

• Posted by Mike The Spike <mtsreborn at yahoo.com> Feb 04, 2001
• 408 views

Hey!
Yall keep mailing me complaints bout' me choking this
place with posts, and then I didn't see a single
damned post by anyone in the last six hours, so I'm
gonna post to keep Topica from deleting the list
because it has being abandoned or some shit ;)


--- Robert Craig <rds at RapidEuphoria.com> wrote:
> Most of the checks that are done inside a library
> routine
> are still there, since the library routines are
> shared
> between the interpreter and the translator. In most
> cases
> this checking adds very little overhead.
> 
> The in-line, generated C code has virtually no
> checks.
> - no subscript out of bounds check
> - no uninitialized variable check
> - no type checks

Hmm...

> The lack of error checking accounts for some of the
> speed-up in translated code, but there are also many
> other
> reasons why translated code is faster than the
> interpreter.
> 
> So why isn't it as fast as hand-coded C?

That's what I was woundering... ;)

> On sieve.ex and shell.ex, I think it's now about
> two thirds as fast as hand-coded C.

Excelent news, ain't it guys?

> It's hard to make it 100% as fast as hand-coded C.
> Some of the main reasons are:
>     - Euphoria doesn't require you to specify your
> data types
>       e.g. a sequence could contain an arbitrary mix
> of data
>       and you can't tell until runtime what the data
> types are
> 
>     - Euphoria looks after all your dynamic storage
> allocation needs.
>       C leaves it up to you to call malloc and free
> and keep track
>       of things.
> 
>     - Euphoria supports integer calculations that
> overflow
>       automatically into floating-point as needed.
> The translator
>       also supports this, and must check for
> overflow.

And if you'd write a C program 'as it should', meaning
with integer to float overflows (tip: Some modern FPUs
make floating point operations faster than some
integer 
operations. Maybe atoms should be declared as
'floats'?
You'll eliminate a lot of checks!),
and garbage collection through refernce counting (read
the article about that on Gamedev.net explaining how
to do it), then any C program will run at 2/3rds its
original speed.
A lot of commercial games out there actually run
2/3rds slower because of (often crappy) memory
handling routines and garbage collection.

Plus, most high-performance games out there were coded
in C++, not C, wich is slower than C anyways (because
of classes, constructors and destructors being called
upon declaration, the size of a class in memory,
etc.).

> Regards,
>    Rob Craig
>    Rapid Deployment Software
>    http://www.RapidEuphoria.com


Keep up the good work, man!
The translator rocks!


Mike The Spike