On 19 Sep 2009, at 10:53, Stéphane Ducasse wrote: > ok I saw smalltalk squeak > but then how do you interpret the graph? Well, the graphs are... creative... At least not intuitive.
Change one of the languages to C, then you will get a feeling for what they try to express. If the first language, you base for comparison, is faster it uses only a fraction of the time the other language needs. The bar will be below the one-line. If its slower, the ratio is higher, it uses x-time the time the other language uses. > > 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 -- 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
