Hi there!
Thanks for the answers, found them very useful
I have a few more questions
Ok!, tried that, it worked:
668407310 bytecodes/sec; 13559830 sends/sec
760772659 bytecodes/sec; 13803237 sends/sec
777524677 bytecodes/sec; 12762744 sends/sec
760772659 bytecodes/sec; 13834279 sends/sec
775757575 bytecodes/sec; 13569800 sends/sec
I read something about intel being faster than AMD for exupery, Do you
know why is that?
> > 2) Tried tinyBenchmarks in VisualWorks (NonCommercial 7.4.1) in my
> > machine, I got:
> > '652,229,299 bytecodes/sec; 89,016,165 sends/sec'
> >
> > Does anyone know Why I get almost 90 million sends/sec?
> > I think It's quite a big difference from previous versions of vw
> >
> > 3) I saw that primitives for #at: and #at:put: are getting inlined, but
> I
> > think they are only implemented for Variable Objects (not for bytes nor
> > Characters nor anything else)
> > Is that true?
>
> It's true. #at: and #at:put: are only implemented for variable
> objects. I should write primitives for other types. Good benchmarks
> that demonstrate the need for such primitives would be nice.
>
I 'll try to check that, thanks
> > 4) In my experiments with exupery, I get an error if I inline too many
> > methods. I think I am getting out of machine registers, for example,
> when
> > I try to compile Integer-#digitDiv:reg:.
> > I get this error In the ColouringRegisterAllocator phase, but it is not
> a
> > "You dont have more registers, dude" kind of error.
> > Is the "no more registers" situation taken into consideration?
>
> I'd guess that it was because a variable was live at an entry point.
> There's a stack tracing bug which I'm just fixing that could have
> caused that.
>
> I use the liveness analyser in the register allocator to catch
> compiler bugs. It's much nicer to catch them there than with crashes.
>
Yes I've seen those kind of errors (variable live at entry point),
corrected them initializing temps with nil.
I think this is something different. In this method of the
ColouringRegisterAllocator:
findNodeToSpill
| spillable |
"This is just a basic heuristic, spill the register that interferes with
the most
other registers. It is possible to do a lot better.
The heuristic should concider how much each register is used while it is
alive"
spillable := spillWorklist select:
[:each | ((self hasSpill: each register) not) and: [each register
isMachineRegister not]].
spillable := spillable asSortedCollection: [:a :b| a spillWeight > b
spillWeight].
^ spillable first
After compiling lots of methods using exupery, it fails with very big
methods because spillable is nil, and spillable first throws an error. If
I make less inlining (for example, not inlining divisions and
multiplications), it compiles ok!
Any ideas?
> > 5) Is there a way to implement indirect jump tables in exupery?
>
> It would be possible. I do use indirect jumps for returns to compiled
> methods. If you look at any method you should see at least one
> indirect jump in the return code. Just jump to a register.
>
Yes, I checked that, but I still need to initialize that register with the
convenient block, but I need to do that without using Jcc (conditional
jumps) to choose from the right one, Any suggestions?
> Bryce
> _______________________________________________
> Exupery mailing list
>
Exupery@...
>
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery>
Thanks a lot
cheers, Guille
_______________________________________________
Exupery mailing list
Exupery@...
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery