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=squeak&box=1 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 <[email protected]>: >>>> 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 >>>>> [email protected] >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- >>>>> project >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> [email protected] >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [email protected] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> [email protected] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > [email protected] > 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 _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
