[REBOL] rebol weak points (i think) Re:(8)
From: agem:crosswinds at: 13-Sep-2000 17:00
[g--santilli--tiscalinet--it] wrote on 13-Sep-2000/11:36:49+2:00
> [agem--crosswinds--net] wrote:
>
> > Compiling the compiler into the runtime? Compilers can be small..
>
> Even if it has to be smart enough to compile REBOL?
>
hehehe. yes. i expect compiling rebol is not that
a great project. Carl has looked for speed, that means,
the way rebol-code -> accociated native code will
be clever&smart short. and that means, inlined it may be
short to.. if i refect on GC-Bug not fixed this long
time.. may mean this would need deep changes.
> > Wheres the problem? yes, by default you have to lookup
> > each call in a table. for speed, to inline the primitives,
>
> Would that really be faster than the current interpreter? Just a
> bit, I think. Is that worth the effort?
>
the stupid inliners in simple forthes doubled speed against the interpreters.
on older not so prefetchy superscalar processors.
hm. lets calculate. newest high-performance-chips:
20-step-pipeline. time for static branches/calls:
resolved early in pipeline, clever prefetchers, may
go till 0. time for often used functions like add,
sub ..: parts of a cycle. one can prefetch value for
next call at start of the first call, AFAIK doubled
speed on apples 68K-interpreter. but: number of available
registers on standart: 8. enough for tricks?
Could mean 20 cycles per rebol-instruction for filling
pipeline + 1/x for real calculating on interpreters.
without optimisations..
> > there is a need for hotspot-style compilers. or marking
> > never-changing code by hand ("compile func"). (like
>
> Yes, but that's something different. You can compile if you pose
> limitations, making REBOL more similar to compiled (or compilable)
> languages. But then, what's the point in using REBOL?
>
> I'd prefer a solution like:
>
> my-native: make native! [
> ; compilable REBOL dialect here
> ]
>
that i mean with marking by hand. hotspot-compilers
do this marking at runtime, analysing if a word can
be changed with current code. if new code comes, they
have to de-optimize (sun is pretty proud about that).
purpose: you can write "open" components which can
be extended, but if you don't extend, they will be
as fast as [make native!] ("final" in java). this
may be hard to check in rebol, where names can be
created on the fly. but it was designed for self,
smalltalk.. lie languages. self is prototype-based..
nearly as hard to optimize as rebol?
an interesting aproach would be to compile whole modules,
then [make component! [a: none .. ] ] instead of [make
native!] :)
> where you can speed up critical code. That would make REBOL the
> most powerful language --- you have speed, and you have a powerful
> high level language.
>
> > if bind is allways bind/copy this works. note we have early binding in rebol,
>
> > which gives very good hints what will be called (can be reduced to indirect a
>
> ddresses IMO).
> > Compiler has to insert calls beetween the addresses, yes.
>
> But then again you need the compiler in the runtime; I have dubts
> that such a "REBOL compiler" could be dramatically faster than the
> current interpreter. If you, instead, express the speed critical
> parts with an ad hoc designed compilable dialect, and then compile
> those, you get a dramatic speed improvement with just a little
> effort.
>
See expectation above for special cases (few time
spend in native libraries). these cases include image-processing,
which may be interesting in rebol.
> > i know SM-code is possible, but is it usefull?
>
> It can be. You have the power, but have to use it with wisdom.
>
not without pc/returnstack-access IMO. otherwise i
can replace te whole function instead of modifying
it.
> > make a block-entry big enough for some usefull code,
> > like add, if, .. and of course indirect call . if
> > you bind to a froozen primitive, copy its code, else
> > insert a call. if you store to a speed-block! , its
> > more costly, and you have to fight with code/data-cache-sync.
> > with fixed block-size one has to insert some nops
> > too. but modern prefetchers may like this way more
> > than interpreter-jumps?
>
> I still think that's not worth the effort, but I might be wrong.
> The "COMPILE ..." or "MAKE NATIVE! ..." solution seems to me much
> simpler and useful.
>
I think too.
> > Can't be long until he thinks that job can be done
> > by Rebol too. if he changes the language a bit.. If
>
> Why change the language, if you can just add a new dialect?
>
because the language _is_ the dialect. it's not only
the syntax (blocks, 0x0) which one should recycle
in dialects, is as much as possible, like names (
'insert , 'if ), assignments ( a: ), argument-order
(desti first) ... result: if you make a dialect for a general-purpose-language,
it should look like REBOL.
second: a heavy problems with script-languages/ native
code is the interface. usually this needs lots of
conveter-code. i don't like [get-block-element-at
ref arg 1 42 ] if i can can do this stuff in a usual
function header..
> If RT just includes some kind of fast "byte code" interpreter or
> compiler, then the compiler from the dialect to teh byte code can
> be easyly done in REBOL. It's much simpler, isn't it?
>
i expect it has kind of "bytecode". i would call it
wordcode
. stored rebol contains native addresses,
which can simply lookupt and jumped to. this way better
especially in calling other REBOL-functions, and having
fixed-size code-parts.
> Just IMHO,
> Gabriele.
> --
> Gabriele Santilli <[giesse--writeme--com]> - Amigan - REBOL programmer
> Amiga Group Italia sez. L'Aquila -- http://www.amyresource.it/AGI/
>
of course IMO too. Otherwise I would write REBOL :)
last note: the /library -interface of /command looks
like an interesting dialect for better optimisation
(fixed types -> fixed offsets in objects). joined
with [make component!], for special speed-parts i
could accept strong typing..
oops, another last note: i have no real need for more
speed till now!! Wow! but i like compilers - techniques
:)
Volker
