Re: mac.exe
>Hmmm, the interesting thing here is that Java is supposedly slower than
>Euphoria already, so programming a Euphoria interpreter in Java would be
>like towing a Mercedes with A Ford Escort, would it not? IOW, perhaps
>it would be a useful learning tool, but I think it might be too slow to
>go anywhere serious.
Now stuff is going to get messy. Sorry, Robert to break your marketing
strategy, but Java is *not* nessecarily slower than Euphoria.
There are 2 reasons why it was times 8 times slower than Euphoria:
1) Benchmarks and common use have little to do with each other. Robert got
to choose the benchmark.
2) The Java Interpreter used was not of the new JIT technology. Which loads
slower, and more memory troubling, however it executes *faster* .. I repeat
.. *faster*
However, again, Java is not Euphoria and speed is not easily compared. For
example compare ASM and C++ using Watcom for example. ASM *in theory* and
*in benchmarks* runs much faster, however when coding a complicated program,
no human is capable of applying the same optimization as a smart compiler
could. That is why most programs are written in C, where some small crucial
parts where brainstormed about what the fastest possible code would be in
ASM and then that code was inlined.
Same goes for Euphoria. Many simpel safe tasks in Euphoria, take loads of
work and run slowly in Java. Simply because the tools dont fit the goal. A
screwdriver gives you more option than a hammer, however jamming nails in
with a screwdriver is still harder than using a hammer. That is again what
you call a *compromise*.. enough anology now.. 
Ralf
|
Not Categorized, Please Help
|
|
