On Mon, Sep 15, 2014 at 6:23 PM, Eliot Miranda <eliot.mira...@gmail.com> wrote:
> Hi All, > > On Mon, Sep 15, 2014 at 6:01 AM, Thierry Goubier < > thierry.goub...@gmail.com> wrote: > >> >> >> 2014-09-15 14:39 GMT+02:00 Clément Bera <bera.clem...@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.goub...@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. > Why so? I am all in for using the VM based technology. Slang is great. Now, we need to interface with the outside world, and then it is C-based at one point. > 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. > Super, that's why I bet my company business on Pharo for software development. I trust you guys. > 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. > Ah, non blocking VM, a super cool thing to have. I am going through hoops at the moment to avoid doing direct SNMP calls to devices from Pharo... > > 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. > That's well said. Let's race to the top! > > 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> > All very interesting things indeed. Now, doing application level code at the moment, I can't really dig into these. But I can use them and kick ass! > > > 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 >> > > -- > in hope, > > Eliot >
