Hi All,
On Mon, Sep 15, 2014 at 6:01 AM, Thierry Goubier thierry.goubier@gmail.com wrote:
2014-09-15 14:39 GMT+02:00 Clément Bera bera.clement@gmail.com:
Hello,
Note that slang is a subset of smalltalk. The Slang compiler does not allow to compile smalltalk to C. It allows to compile a smalltalk with restricted message sends and classes to C.
Yes, I am aware of that. I remember that from the very beginnings of Squeak.
Wasn't Smalltalk/X the one which had a more complete version of that C translation? I did an internship in a French company who had a Smalltalk to C translator done for them a long time ago.
2014-09-15 13:28 GMT+02:00 Thierry Goubier thierry.goubier@gmail.com:
Hi Phil,
thanks for the update on Slang to C. Allways significant to have that.
Two open questions:
- would a slang to x86 asm via NativeBoost be doable / a nice target?
Yes it would be interesting. However, by having a Slang to C compiler, we're platform-independent, we can compile the C code to x86, x86_64 and ARM quite easily (some part of the VM are already processor dependent, but not so much). Targeting direct machine code implies evolving the Slang compiler for each new assembly code we support. It sounds like a lot of engineering work compared to our resources and the gain.
It would allow JIT-type compilation experiments than a Slang-to-C chain isn't designed for :) With a lot more work doing the various NB ports, of course.
- would targetting LLVM-IR be of interest?
If you compile the C code with Clang instead of gcc, which starts to be
the case because of the lack of support for gcc in the latest Mac OS X, you are already using LLVM IR because Clang uses it. As the VM use the GNU C extensions to improve performance, I do not think that targeting directly the LLVM IR would greatly improve performance. So it sounds like quite some engineering work for no gain.
I would not suggest replacing C by LLVM-IR for VM work, in part because LLVM-IR is not what I would call a readable source code format... But I do know that even when doing C to C rewritting for embedded compilation, there is some low-level code that you can't write in C.
I find this whole discussion depressing. It seems people would rather put their energy in chasing quick fixes or other technologies instead of contributing to the work that is being done in the existing VM. People discuss using LLVM as if the code generation capabilities inside Cog were somehow poor or have no chance of competing. Spur is around twice as fast as the current memory manager, has much better support for the FFI. Clément and I, now with help from Ronie, are making excellent progress towards an adaptive optimizer/speculative inliner that will give us similar performance to V8 (the Google JavaScript VM, lead by Lars Bak, who implemented the HotSpot VM (Smalltalk and Java)) et al. We are trying to get person-power for a high-quality FFI and have a prototype for a non-blocking VM. When we succeed C won't be any better and so it won't be an interesting target. One will be able to program entirely in Smalltalk and get excellent performance. But we need effort. Collaboration.
Personally I feel so discouraged when people talk about using LLVM or libffi or whatever instead of having the courage and energy to make our system world-class. I have the confidence in our abilities to compete with the best and am saddened that people in the community don't value the technology we already have and can't show faith in our abilities to improve it further. Show some confidence and express support and above all get involved.
Collaborators http://www.mirandabanda.org/cogblog/collaborators/ Cog Projects http://www.mirandabanda.org/cogblog/cog-projects/ Spur 1/3 https://www.youtube.com/watch?v=k0nBNS1aHZ4&index=49&list=PLJ5nSnWzQXi_6yyRLsMMBqG8YlwfhvB0X Spur, a new object representa... http://www.slideshare.net/esug/spur-a-new-object-representation-for-cog Sista: Improving Cog's JIT performance 1/2 https://www.youtube.com/watch?v=X4E_FoLysJg&list=PLJ5nSnWzQXi_6yyRLsMMBqG8YlwfhvB0X&index=76 Sista: Improving Cog’s JIT pe http://www.slideshare.net/esug/sista-talkesug2.. Lowcode: Redoing NativeBoost ... http://www.slideshare.net/esug/03-lowcodeslides
However, I think Ronie was interested in doing such work. If he succeeds
and reports performance improvement, then we can consider using his compiler to compile the VM.
Keep us posted!
Thierry