On 19 Sep 2009, at 08:46, Igor Stasenko wrote:
Lua is SLOW :)
But still - you can go and see the speed comparison of different numerical algorythms implemented in different languages. Squeak leaves Lua far behind.. That sounds like FUD. But, maybe I misunderstand you here.
However, Lua 5.x is FAST, especially for an interpreted language. Its register-based implementation seems to be much better for interpretation in terms of speed than the stack-based bytecode in Squeak. See: http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=lua&lang2=... And: Virtual Machine Showdown: Stack Versus Registers Yunhe Shi and Kevin Casey and M. Anton Ertl and David Gregg ACM Trans. Archit. Code Optim.4(4):1--36(2008) Best regards Stefan
Especially, i think, if you use language for scripting, so scripts will tend to contain more logic than heavy numeric crunching (because for numerical crunching hardcore devs using C & GPU) - smalltalk will win even more.
Stef
On Sep 19, 2009, at 5:28 AM, Igor Stasenko wrote:
2009/9/18 Stéphane Ducasse <stephane.ducasse@inria.fr>:
yes this is one of my dream but .... I'm not good enough to make it come true.
Lua is specifically designed from the very starting to live well as embedded system, written in C. No wonder that its having very good C interoperability. And that's why, at the time i found the smalltalk, first thing i thought, that creating an interoperability layer between C and smalltalk will unleash its potential for use in scripting. Unfortunately, almost every implementation i found & read about smalltalk vere designed as a self-sustained (or self-sufficient) sandboxed environment with a little care about host interoperability in mind. Even existence of FFI in Squeak doesn't changes that, because Squeak VM architecture as well as language-side design prevents you from controlling interpreter from outside. A less painful way for achieving a kind of embedding, as Andreas mentioned, that you can write the plugin which using callback machinery and create an image which simpli 'listening' for calls from outside then handle them and put response back. But i can't tell, how efficient it could be comparing to Lua scripting interface.
For instance, if i would want to enable the dynamic primitive publishing (which host application may want to use), then this would require VM changes. That's why i proposed , some time ago, to modify the VM internal infrastructure to have a kind of namespace, which is dynamically built-up using associations of symbols (C strings) with some pointer/values. Then you can publish primitives at any time you wanting to, replace them at run time and do many other kind of tricks, which is possible, when function pointer is not bound at compile time, but discovered by VM at run time. At some point we could even use a JIT to generate the primitives and then let VM to pick them up at run time. This means, that at some point you could JIT everything you need, and replace the C-compiled VM stuff after booting the image, and from now on, VM is not something which is made from stone like all C-compiled binaries. So different images could carry own system inside which, once its booted up, no longer needs the statically compiled crap. This also means, that by having a good JIT and VM tuned for this, we don't really need writing any C code anymore, because main reason why we doing this is speed and easy interoperability with host environment. :)
Stef
On Sep 18, 2009, at 6:40 PM, Lawson English wrote:
Johan Brichau wrote:
On 16 Sep 2009, at 20:37, Ken Treis wrote:
* I'm creating a partial Alien library for GemStone so that I can use the CairoGraphics package in both Pharo and GLASS. But on x86-64, there there's a size difference between a pointer/long and an integer. It'd be nice to have some more explicit APIs on Alien, so I could say "Alien newCInteger" or "Alien newCLong" and have the platform return me the proper size Alien. Even without the platform size differences, it seems awkward to use "Alien newC: 4" everywhere I want an integer, "Alien newC: 8" where I want a double, etc.
Exactly.
It becomes worse once you start having structs and nested structs or structs with pointers to structs ;-)
I'm using Alien as the FFI to port JavaConnect from Visualworks to Pharo/Squeak. As you say, it is a pain to work at such a low- level compared to the DLLCC in VW. I am planning to do some work on creating a higher-level interface for it such that we can operate it as you mention, including the correct bytesizes for all platforms.
At the moment, I'm mostly focusing on getting the port to work right before I start creating an interface on top of the current Alien interface.
Something to keep in mind is the need for a straightforward way of going the other way: John Mcintosh's port of the Squeak VM to iPhone implies that the same thing could be done in other Lua-ish situations, allowing people to use smalltalk syntax for game scripting. With the right libraries for an IDE, I would think squeak could be very attractive to at least some people in place of/in addition to using Lua.
Lawson
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Stefan Marr Software Languages Lab Former Programming Technology Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://prog.vub.ac.be/~smarr Phone: +32 2 629 3956 Fax: +32 2 629 3525