RE: Digest for EUforum at topica.com, issue 5757
Cuvier Christian wrote:
> A very large improvement in some specific situations that may happen often,
> all right. But reducing 0.5ms to 0.3ms, which is a 40% gain, isn't quite
> important except in a hot loop. Unrolling the loop will give you far better
> results then. Hence I still am skeptic about the net gains and hence the
> priority given to this point.
No. If I remember correctly this issue can effect performance between 100 and
200 times. Robert probably wont be able to improve this much, but anything helps
I guess.
> That's right, and matches the question I was asking: is Eu a language
> specifically targetting 100MHz- machines? It looks like so, and personally
> I'll gain nothing at all with this, while still losing because of
> limitations or excessive rigidity in some other areas of the language.
Well not anymore now is it! In fact it's not even really suitable for 1000 MHz
machines either. You will want at least 1500 MHz for acceptable loading
performance of large programs, otherwise you'll need fork out cash for the binder
or translator to remove the parsing overhead. The free translator substitues the
parsing delay with a nag screen delay.
I'm happy Robert is willing to try and improve it some more but the fact is it's
basically as fast as it will ever be. The new concept of parsing all the code
before execution and translating/compiling the Euphoria coded front-end to C is
whats causing it. Translating/compiling alone is around 9 to 15x slower than
handwritten and optimized C (which the previous back-end was), plus get an
additional performance loss with "full parse before exectution" verses the
"parse-on-demand" (2.4 and earlier) system.
> Eu is no longer an interpreted language, from v2.5 on.
> It parses the whole text before executing anything, and no modification to
> that text gets reflected in program execution. When I compile a Pascal
> program, it's exactly what I get, without any more hassle. So that selling
> point is just no longer true technically.
> The compiler has hardly any option (the "with/without" directives), and the
> binder has hardly any, that's all the difference with, say, Pascal. And it
> is really unfrequent that I have to tinker with compile options, even with
> gcc.
> Euphoria compiles to bytecode just like Java, but less coder friendly and
> without the benefits of hybrid compilation. In what respect is it
> interpreted anymore?
You know thats interesting you say that. I wondered this myself for some time.
So Euphoria 2.5 and beyond is now basically a virtual machine?
> Try the FreePascal compiler. It will give you code that you can tweak for
> speed, contrary to Python/Ruby, and the right mix of
> procedural/object-oriented programming tools that allows using it for a
> broad spectrum of purposes. Purely OO languages are a pain sometimes, and
> purely procedural ones too, usually not at the same time though 
. Of
> course it has its own quirks, just like Euphoria.
Maybe I'll take a look at Free Pascal. I hear it's somewhat compatable with
Delphi? It might be useful to learn a little Pascal. But I'll probably still like
Euphoria better.
Regards,
Vincent
|
Not Categorized, Please Help
|
|
