1. Translator Runtime Checking
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.
Mike The Spike
2. Re: Translator Runtime Checking
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
3. Re: Translator Runtime Checking
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
