Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search

[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 -- >
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