1. Translator Runtime Checking
- Posted by Mike The Spike <mtsreborn at yahoo.com> Feb 04, 2001
- 416 views
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
- Posted by Robert Craig <rds at RapidEuphoria.com> Feb 04, 2001
- 420 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
3. 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