On 03/giu/06, at 05:21, Norman Palardy wrote:
Compile is a pretty generic term now
Java is, in most strict definitions, compiled.
Now, it's not compiled to machine code, but it is compiled.
Run Rev sounds about the same
I think you are right.
However, I would see this discussion under another point of view:
Is the RunRev intermediate code faster than the native code generated
from RB?
Intermediate code need an additional step for native code translation
while native code doesn't, therefore I would answer no.
But... we all know the RB compiler lacks in code optimization. It
mainly leverage on a static runtime which is called from compiled
code. And this leave some space in performance consideration. I talk
about performance because the fact RB is runtime-based almost
vanishes many of the advantages of having native code.
So a better question would be:
Are we sure the RB runtime-based native code is faster than the
RunRev intermediate code?
An answer to this question is not easy, however I'm almost sure that,
in many operations, the performance is similar. I guess that in some
other tasks RB is faster than RunRev and vice-versa.
But the obvious question is:
Is the RunRev Universal Binary intermediate code faster than the rb
PowerPC Only runtime-based native code?
At least for Intel Macs I guess YES! I don't think there is a chance
that an emulated code could be faster than native code.
So, I would bring the whole discussion to another point:
With a big approximation, just for the sake of the discussion, we
could say they are equivalent in performance. But the key fact is
they are VERY different tools. RB is much closer to a traditional low-
level language, while RunRev definitively has an high level approach.
This also split the target audience in two different categories and,
from my experience, I doubt a RunRev user would be comfortable with
RB and vice-versa. I'm much more comfortable with traditional
computer languages and therefore, using RunRev is a pain for me. If
you ask to a RunRev user, he probably tell that using RB is too much
complicated.
This fact could easily end the discussion: They are different
products and thus comparing the performances is not (so) important.
However, I would change the focus again. And this time to bring the
discussion to the original topic.
This bring to another question:
Is there a valid reason because an intermediate code interpreter
could be easiest and fastest to port to Universal Binary than a
native code compiler?
I'm not (and I don't pretend to be) an expert on this topic, but I
can't see any valid reason. At least under the technical aspect.
If someone can elaborate on this, I would be glad to learn something.
So, why we are still on PowerPC native code only?
Can someone answer to this question?
We are stuck on a press release saying that "REALbasic users will
have the fastest, easiest transition to Mac OS X on Intel." (sic)
I know it's too early for Santa Claus letters, but I wish to
anticipate mine:
I would like to have better compiler. A smart compiler capable of
doing effective code optimization, smart linking and capable of
generate different types of objects, not only applications. Possibly
a command line compiler and (why not) GCC-based. I would also like to
have an open file format for sources like plain text. This could give
us the ability to have the compiler, the debugger and the IDE as
three different entities. This also would open RB to alternative IDEs
(why not), even written in RB. Needless to say this also would make
easier the UB transition.
Please, Geoff and all the RS crew, give us a REAL compiler. Thank you!
Massimo Valle
Chiacchiera con i tuoi amici in tempo reale!
http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
