Hi stefan do you what they are really comparing? because Smalltalk looks mysterious to me.
Stef On Sep 19, 2009, at 10:41 AM, Stefan Marr wrote: > > 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 _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
