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