Re: Muhahahaha!
>> I will give you all the money on my bank account if Euphoria is not
>> at least 200 times slower in total than VC++ 6.0.
>
>Please make check payable to:
> Rapid Deployment Software
> 130 Holm Crescent
> Thornhill, Ontario
> L3T 5J3
> CANADA
LOL! Hold your horses, I need proof first, and you can't deliver it.
>> I saw a kid coming in here with his Euphoria Vs. VC++
>> benchmark showing Euphoria was 250 times slower
>> than VC++ 5.0, wich was 100% correct and the absolute truth,
>> and RDS tries to muffle his results away with some fake talk
>> like "oh but the C compilers often strip out code and those 10
>> benchmarks weren't actually running.." DUH? That kid believed it
>> and apologised! Offcourse a C compiler strips out some code
>> wich is NEVER CALLED, but not critical code wich is called
>> thousands of times like that!
>
>The code was supposed to be executed thousands of times,
>but since it didn't calculate anything useful, the C compiler
>optimized it away *completely*. Tiny, artificial benchmarks
>like this are not very useful. I could write a tiny benchmark
>that would show interpreted Euphoria to be 250x faster
>than compiled C. (strlen() in C vs length() in
>Euphoria.)
That's because strlen() runs through the array of chars each time it's called,
and length() simply retrieves an allready calculated length wich is stored along
with the sequence. And about that benchmark. No. I wrote my own benchmarks, and
considered the fact that the C compiler can cut away code if it does nothing
usefull, so I simply compiled them without any optimisations and checked the
produced assembly code to make sure nothing was being cut away, and Euphoria is
still hundreds of times slower.
Don't take my word for it, though, if you truly do not know this, and do your
own checks.
>> It's being compared to interpretters written in the 70's,
>> and then it draws the conclusion that it's faster!
>
>When was Perl written?
>When was Python written?
>When was Java written?
Where are Perl vs Euphoria benchmarks in the package?
Where are Python vs Euphoria benchmarks in the package?
Where are Java vs Euphoria benchmarks in the package?
Clearly you only distributed that wich proved Euphoria to be fast.
>> Then the Euphoria documentation says something like
>> "We never met an interpretter that was faster than Euphoria"
>
>We haven't. Have you?
Yes. Many JAVA byte-code interpretters are faster than Euphoria in many aspects.
And many Perl and Python iterpretter are faster than Euphoria aswell.
>> All you guys are thinking "but what about Euphoria being
>> 8x faster than JAVA?". Yeah right, READ WHAT IT SAYS!
>> It don't say RDS wrote a benchmark program in Euphoria
>> *and* JAVA and the results showed Euphoria was 8x faster,
>> it says that THE TIME IT TAKES TO READ IN AND START
>> EXECUTION ON A PROGRAM IS 8X FASTER IN
>> EUPHORIA COMPARED TO JAVA!!!!
>> Understand? It's just saying that Eu's parser is 8x faster
>> than JAVA's, not that JAVA programs run slower
>> than Euphoria programs.
>
>Wrong. We translated sieve.ex to Java and ran it with
>the latest Java interpreter that existed at that time.
>We did *not* include the fact that Euphoria starts up in
>a tiny fraction of a second, whereas Java takes longer.
>We only timed the loops. Since then Java *compilers*
>have become available. They are faster than the original
>Java interpreter (but with the Translator,
>Euphoria is now much faster on sieve, shell
>and others too).
First, that message onyour site does give the impression that only the time
taken to execute the programs was measured. Second, many ofthose Java "compilers"
are actually only compiling to byte-code form, and still interpret the source at
run-time. Infact, and JIT compiler is actually an interpretter, because an
interpretter is a compiler that compiles programs whenever they need to be ran,
and not once and for all. So, you do know Java interpretters can be faster than
Euphoria? So you admit to have met faster interpretter than Euphoria? And third,
I sure hope that the translator will be faster than any intepretter out there,
becuause if it is not, then you did not take full advantage of the C programming
language.
>> 2. Euphoria users can't produce .dlls, .ocxs or shared libraries,
>> nor object files, and restrict Euphoria to producing EXEs and
>> EXEs alone.
>
>static and shared libraries and object files
>will be possible soon using the Euphoria to C Translator.
This actually sounds good...
But with C I can do this allready, and atleast I'll have programs out there that
can actually call the routines I store in my DLL or shared library, and don't
have to go through parameter tranformation overhead, plus what good is writing
shared libraries if you can't share anything but those routines that don't accept
arrays, since Euphoria can't understand C arrays and convert them to sequences
(why I don't know...).
>> 4. They support only 3 platforms, and that truly is *NOT*
>> going to cut it.
>
>We intend to support more platforms, but we've
>already covered what 90% of PC programmers are using.
Actually, what platform the PC programmers are using does not matter that much.
Because a lot of them are writing programs on the PC for other platforms. I never
saw a MIPS programmer code on his Playstation using his Joystick.
If you truly want to support other platforms, I suggest supporting something
like the MIPS architecture or the RISC architecture instead of coming up with a
Euphoria For BeOS or something. Support MIPS and you support various gaming
consoles and workstations, etc. while supporting yet another PC-based OS like
BeOS you do not support anything attractive.
>Regards,
> Rob Craig
> Rapid Deployment Software
> http://www.RapidEuphoria.com
>
Now I do have respect for you because you did lower yourself to my standards --
flaming, yet attempted to solve this through adult discussion.
Admitted, I did come down on you hard, but as it stands, you have not proven
that Euphoria lives up to your claims.
Infact, I *can* prove *my* claims.
Because your web browser probably contains a Java interpretter wich is faster
than Euphoria right now, unless you have an old web browser.
Unless a Euphoria loop runs exactly as fast as a compiled C loop, there realy
won't be a market for Euphoria. Time has proven this, time has proven that
Euphoria needs change. And the change you attempt to give it, a Translator, won't
work out since you will use Goto's instead of native flow control, meaning
Euphoria will still be the same Euphoria, only with the title of being compiled,
but still slower than what serious programmers can cope with.
A last tip from me: "while 1 do" becomes while(1) in C! "procedure test()"
becomes void test(), and test() becomes test();! Unless so, I see no reason to
believe the translator will be any better than the interpretter.
*********************************************
Want free email? Sign up at http://www.freeze.com !
|
Not Categorized, Please Help
|
|
