1. RE: Digest for EUforum at topica.com, issue 5757
> Subject: Re: Rob: List?
>
>
> posted by: Vincent <darkvincentdude at yahoo.com>
>
> CChris wrote:
>
> >> 6. front-end optimization of temps - fewer temps gives
> better performance
>
> >> 7. try again to speed up scanning/parsing/emiting (front end)
>
> > Are you sure the time you'll spend in these tricky
> optimisations will not
> > outweigh the sum of all execution time gains achieved through them?
> > Perhaps most Eu users still use 486s or older, in which
> case these are relevant.
>
> > If not, see my final comments.
>
> #6 is a very important. In some cases it can cause a very
> large performance drop. I dont know how effective Rob will be
> at improving this for us, but I will say anything is better
> than nothing.
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.
>
> #7 is useful on all systems five years old or more. You will
> see a very noticable parsing delay even on a Pentium III
> machine when trying to run a large program like Win32Lib IDE.
> On a 386 or 486 any medium to large size program will take
> between tens of seconds to a few minutes to load. The IDE
> takes almost four minutes to load to the splash screen on my
> 486 with v2.5!
>
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.
I am not saying that performance is not important. But I'd rather save hours
of bug hunting because I have less hoops to run through (some call them
"workarounds") than a couple seconds, or even minutes, when loading the IDE,
which I don't use much anyway.
> So yes, I strongly support these optimization efforts and
> look forward to them. I'm not expecting any miracle
> improvements but at least marginal will suffice. Whatever
> Robert can do to improve these to his maximum ability is all
> that I could hope for.
>
> >> 8. Translator optimizations:
> >> - translator: if a call_proc/call_func has an
> argument sequence where
> >> all the elements are known to be integers, we
> shouldn't bother to
> >> emit Ref's on the elements
>
> >> - could easily optimize code generation for compare()
> in translator
>
> > Ok, these are probably useful. When I *really* (and rarely)
> need raw speed,
>
> > I directly code in C if asm is not an option. Here again,
> are these little
> > optimisations worth your efforts?
>
> Any optimizations are worth the effort in Euphoria at least.
> One of the biggest selling points of Euphoria is it's
> performance as an interpreted language.
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?
> If that did not count
> we'd likely be better off using Python or Ruby with complete
> standard libaries and large supportive communities.
>
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.
CChris
>
> Regards,
> Vincent
>
>
2. 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
3. RE: Digest for EUforum at topica.com, issue 5757
Most modern interpreters are virtual machines. Most modern interpreters compile
to some intermediate code. This is not a new thing. QBasic did it. I can't really
think of any interpreter that doesn't.
Euphoria is still an interpreter.
--
"Any programming problem can be solved by adding a level of indirection."
--anonymous
"Any performance problem can be solved by removing a level of indirection."
--M. Haertel
"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare
j.
