OpenEuphoria

Re: Translator Runtime Checking

• Posted by Robert Craig <rds at RapidEuphoria.com> Feb 04, 2001
• 419 views

MTS writes:
> I was just woundering wich runtime checks the
> translator doesn't perform wich the interpreter does
> perform.
> I had some major (read: 10 times faster) speed boosts
> using the translator for DJGPP lately, and I don't
> think it's all related to the compilation vs
> interpretation thing.

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

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?
On sieve.ex and shell.ex, I think it's now about
two thirds as fast as hand-coded C.
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.

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