Hi there! Thanks for the answers, found them very useful I have a few more questions
Guillermo Adrián Molina writes:
Hi list, I been playing around with exupery. And now I have a few
questions:
- I cant get tinyBenchmarks working, neither in linux, nor in windows,
Downloaded all the staff from: http://wiki.squeak.org/squeak/Installing+Exupery
used: http://ftp.squeak.org/Exupery/vms/exupery-vm-0.11-linux.tz in
linux
and: http://ftp.squeak.org/Exupery/vms/exupery-vm-0.11-win32.zip in
windows
with prebuild image:
http://ftp.squeak.org/Exupery/images/exupery-0.10.tz
Examples run ok, but when I try to run tinyBenchmarks I get
segmentation
faults
Try using the 0.11 Exupery VM with Exupery 0.11. Exupery VMs must match the Exupery version. The interface between Exupery and the VM is still evolving.
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?
- 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
- 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
- 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?
- 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@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/exupery
Thanks a lot cheers, Guille