[Vm-dev] Re: [Pharo-dev] Parsing Pharo syntax to C/C++

[Göran Krampe]

Hi Eliot and all!

Since I work with Ron at 3DICC and Cog is vital to us, I wanted to chime 
in here.

On 09/15/2014 06:23 PM, Eliot Miranda wrote:
> 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.

One thing you need to understand Eliot is that most of us don't have the 
mind power or time to be able to contribute on that level.

But still, a lot of us are tickled by ideas on the low level - and thus 
ideas like reusing LLVM, reusing some other base VM, cross compilation 
etc - pop up.

Don't put too much into it - I am always toying with similar ideas in my 
head for "fun", it doesn't mean we don't also see/know that *real* VM 
work like Cog is the main road.

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

Let me just mention LuaJIT2 - besides very good performance, among other 
things it sports a *very* good FFI. Well, in fact Lua in general has 
several FFIs and tons of C++ bindings tools too - so IMHO anyone doing 
work in that area should take a sneak peek at LuaJIT2.

And this is a truly "sore" area in Smalltalk since eternity. If we had 
something as solid as the stuff in the Lua community - then Cog and 
Smalltalk could go places where it haven't been before I suspect.

If we look at the codebase we have at 3DICC - a very large part consists 
of complicated plugin code to external libraries and accompanying 
complicated Smalltalk glue.

Also, if we compare the Lua community with the Squeak/Pharo community, 
it is quite obvious that the lack of really good FFI solutions leads us 
to "reinvent" stuff over and over, often poorly, while the Lua people 
simply wrap high quality external libraries and that's it. Done.

Of course still also stems from the very different background and 
motives behind the two languages and their respective domains, but still.

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

Don't feel discouraged - its just that 99% of the community can't help 
you. :) Instead we should feel blessed that we have 1 Eliot, 1 Clement, 
1 Igor and 1 Ronie. Do we have more?

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

Let me then make sure you know that 3DICC values *all* work in Cog 
*tremendously*.

As soon as you have something stable on the Linux side - we would start 
trying it. Just let me know, on Linux (server) we run your upstream Cog 
"as is". In fact, I should probably update what we use at the moment :)

Every bit of performance makes a big impact for us - but to be honest, 
what we would value even more than performance would be ... robustness. 
I mean, *really* robust. As in a freaking ROCK.

An example deployment: More than 3000 users running the client on 
private laptops (all Windows variants and hw you can imagine, plus some 
macs) and the server side running on a SLEW of FAT EC2 servers. We are 
talking about a whole BUNCH of Cogs running 24x7 on a bunch of servers.

We experience VM blow ups on the client side, both Win32 and OSX. OSX 
may be due to our current VM being built by clang, but I am not sure. 
Our Win32 VM is old, we need to rebuild it ASAP. Hard to know if these 
are Cog related or more likely 3DICC plugin related, but still.

But the client side is still not the "painful" part - we also experience 
Linux server side Cogs going berserk (100% CPU, no response) or just 
locking up or suddenly failing to resolve localhost :) etc. I suspect 
the networking code in probably all these cases. Here we do NOT have 
special 3DICC plugins so no, here we blame Cog or more likely, Socket 
plugin. Often? No, but "sometimes" is often enough to be a big problem. 
In fact, a whole new networking layer would make sense to me.

Also... we need to be able to use more RAM. We are now deploying to 
cloud servers more and more - and using instances with 16Gb RAM or more 
is normal. But our Cogs can't utilize it. I am not up to speed what Spur 
gives us or if we in fact need to go 64 bit for that.

regards, Göran