Vm-dev February 2011

vm-dev@lists.squeakfoundation.org

25 participants
79 discussions

[OT] Why PHP is better than Ruby
by Igor Stasenko 25 Feb '11

25 Feb '11

My friend gave me a fun post.. http://najafali.com/php-is-better-than-ruby.html rofl... -- Best regards, Igor Stasenko AKA sig.

1 0

Missing plugins in Mac VM 5.7.4
by Matthew Fulmer 24 Feb '11

24 Feb '11

The mac VM 5.7.4 is missing at least the following plugins, needed by Cobalt: Asynchfileplusin B3dAccelerateorPlugin Croquetplugin FloatmathPlugin JoysticktablePLugin MidiPlugin Mpeg3Plugin SerialPlugin -- Matthew Fulmer (a.k.a. Tapple)

1 0

Re: [squeak-dev] [ANN] Squeak 4.2
by Levente Uzonyi 22 Feb '11

22 Feb '11

On Tue, 15 Feb 2011, Alexander Lazarević wrote: > 2011/2/11 Chris Muller <ma.chris.m(a)gmail.com> > >> I'd like to call Squeak 4.2 finally officially released now. >> > > The all-in-one package most likely will crash on linux systems at some point > because of the UUID bug. Maybe this should be repackaged without the UUID > plugin. If you have a VM-OS combination that crashes because of the UUID bug, you could give this version of the plugin a try: http://leves.web.elte.hu/squeak/so.UUIDPlugin Details about the changes in this plugin are available here: http://bugs.squeak.org/view.php?id=7358#14053 Levente > > Alex >

3 3

Why #cannotInterpret: does not works in Cog?
by Igor Stasenko 22 Feb '11

22 Feb '11

---------- Forwarded message ---------- From: Igor Stasenko <siguctua(a)gmail.com> Date: 22 February 2011 00:58 Subject: Re: [Vm-dev] Why #cannotInterpret: does not works in Cog? To: Eliot Miranda <eliot.miranda(a)gmail.com> On 21 February 2011 19:28, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Igor, > > On Mon, Feb 21, 2011 at 7:44 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> It looks strange, because from what i see in sources it should work. >> >> The implementation of #lookupMethodInClass: is the same as in Squeak VM, >> which leaves me clueless, what goes wrong in Cog, that breaking it. > > Come on lad, you know better than this :) What's the reproducible case? > The code and tests you sent me work. So as far as I'm aware the r2361 VMs > should support cannotInterpret:. But without tests and error cases I can't > do more. So chapter and verse, code and crash, please. Issue: http://code.google.com/p/pharo/issues/detail?id=3648 Code: http://pharo.googlecode.com/issues/attachment?aid=-2688922205745305798&name… Tests: http://pharo.googlecode.com/issues/attachment?aid=7497500072193223103&name=… I built Cog mac vm from cmake configs. Not works :( So, question remains same: what is wrong with it, because from source code POV it should work. -- Best regards, Igor Stasenko AKA sig. -- Best regards, Igor Stasenko AKA sig.

2 1

Re: [squeak-dev] Linux VM can't read files from /proc
by Alexander Lazarević 22 Feb '11

22 Feb '11

Ah, you're right. The Squeak VM gets the file size via stat and does not just read the contents from the file. So for squeak the file looks just empty. That's a shame because /proc/self/environ would be an easy way to access the environment variables from within the image without any need to add a specific primitive to the VM or use FFI. Alex 2011/2/21 Tony Garnock-Jones <tonyg(a)ccs.neu.edu> > On 2011-02-21 4:35 PM, Alexander Lazarević wrote: > >> Does anybody know why the linux vm can't read files from the /proc >> filesystem? The VM is able to open the files but the size is 0!? A >> simple less or cat on these files just works fine ... >> > > Is it just the sizes that are zero, or does actually reading from them fail > too? A stat() (or for that matter an ls -l) will return a zero size, but a > read() in C will return data. > > Regards, > Tony >

2 2

Linux VM can't read files from /proc
by Alexander Lazarević 21 Feb '11

21 Feb '11

Does anybody know why the linux vm can't read files from the /proc filesystem? The VM is able to open the files but the size is 0!? A simple less or cat on these files just works fine ... Alex

1 0

Why #cannotInterpret: does not works in Cog?
by Igor Stasenko 21 Feb '11

21 Feb '11

It looks strange, because from what i see in sources it should work. The implementation of #lookupMethodInClass: is the same as in Squeak VM, which leaves me clueless, what goes wrong in Cog, that breaking it. -- Best regards, Igor Stasenko AKA sig.

2 1

VM Maker: CMakeVMMaker-IgorStasenko.30.mcz
by squeak-dev-noreply＠lists.squeakfoundation.org 21 Feb '11

21 Feb '11

Igor Stasenko uploaded a new version of CMakeVMMaker to project VM Maker: http://www.squeaksource.com/VMMaker/CMakeVMMaker-IgorStasenko.30.mcz ==================== Summary ==================== Name: CMakeVMMaker-IgorStasenko.30 Author: IgorStasenko Time: 21 February 2011, 5:20:45 pm UUID: c70e38fa-45bf-4e53-a3b8-5990fb1b4ad9 Ancestors: CMakeVMMaker-IgorStasenko.29 - little lifting methods up to base class

1 0

Re: [Pharo-project] Cog VM -- Thanks and Performance / Optimization Questions
by Eliot Miranda 19 Feb '11

19 Feb '11

Hi John, good questions. On Thu, Feb 17, 2011 at 6:21 AM, John B Thiel <jbthiel(a)gmail.com> wrote: > Cog VM -- Thanks and Performance / Optimization Questions > > > To Everyone, thanks for your great work on Pharo and Squeak, and to > Eliot Miranda, Ian Piumarta, and all VM/JIT gurus, especially thanks > for the Squeak VM Cog and its precursors, which I was keenly > anticipating for a decade or so, and is really going into stride with > the latest builds. > > I like to code with awareness of performance issues. Can you tell or > point me to some performance and efficiency tips for Cog and the > Squeak compiler -- detail on which methods are inlined, best among > alternatives, etc. For example, I understand #to:do: is inlined -- > what about #to:do:by: and #timesRepeat and #repeat ? Basically, I > would like to read a full overview of which core methods are specially > optimized (or planned). > The bytecode compiler inlines a set of selectors if the arguments are suitable (typically literal blocks). The standard compiler's list is MessageNode classPool at: #MacroSelectors, e.g. #ifTrue: #ifFalse: #ifTrue:ifFalse: #ifFalse:ifTrue: #and: #or: #whileFalse: #whileTrue: #whileFalse #whileTrue #to:do: #to:by:do: #caseOf: #caseOf:otherwise: #ifNil: #ifNotNil: #ifNil:ifNotNil: #ifNotNil:ifNil: Note that Nicolas Cellier has just added support for inlining repeat and timesRepeat in Squeak trunk. > I know about the list of NoLookup primitives, as per Object > class>>howToModifyPrimitives, supposing that is still valid? > Not for Cog. While #== and #class are inlined all other primitives are looked up. > What do you think is a reasonable speed factor for number-crunching > Squeak code vs C ? I am seeing about 20x slower in the semi-large > scale, which surprised me a bit because I got about 10x on smaller > tests, and a simple fib: with beautiful Cog is now about 3x (wow!). > That range, 3x tiny tight loop, to 20x for general multi-class > computation, seems a bit wide -- is it about expected? > Are you saying that you have a macro benchmark that is 20 times faster in C than in Cog? Cog, while faster than the interpreter, is still a non-inlining, non-globally-optimizing system and so performance is certainly to be expected to be worse than C. But 20x sounds a little high so your benchmark could be useful. If you can post this please do. The current state of Cog is that the new code generator gives a significant speed-up but that the object model and garbage collector remain substantially the same as the Squeak interpreter. The GC is slow and badly needs replacing. The object model is both slow, especially for class access, which slows down all sends a little, and over-complex, which means that several performance-critical primitives have yet to be implemented in machine-code, especially at:put:, basicNew, basicNew:, and closure creation, all of which currently require expensive calls into C instead of using inline machine code. I would expect that improving all these could add at least another factor of 33%. I'm trying to find funding to work on these two issues ASAP. > My profiling does not reveal any hotspots, as such -- it's basically > 2, 3, 5% scattered around, so I envision this is just the general > vm/jit overhead as you scale up -- referencing distant objects, slots, > dispatch lookups, more cache misses, etc. But maybe I am generally > using some backwater loop/control methods, techniques, etc. that could > be tuned up. e.g. I seem to recall a trace at some point showing > #timesRepeat taking 10% of the time (?!). Also, I recall reading > about an anomaly with BlockClosures -- something like being rebuilt > every time thru the loop - has that been fixed? Any other gotchas to > watch for currently? > BlockClosures for non-inlined blocks are still created when mentioned. So if you do have a loop which contains a block creation, consider pulling the block out into a temp variable. > (Also, any notoriously slow subsystems? For example, Transcript > writing is glacial.) > Someone should replace the Transcript's reliance on (I think) some kind of FormMorph which moved huge numbers of bits on each write. But this is not a VM issue. It's a Smalltalk issue. Whoever did this would instantly become a hero. > The Squeak bytecode compiler looks fairly straightforward and > non-optimizing - just statement by statement translation. So it > misses e.g. chances to store and reuse, instead of pop, etc. I see > lots of redundant sequences emitted. Are those kind of things now > optimized out by Cog, or would tighter bytecode be another potential > optimization path. (Is that what the Opal project is targetting?) > There is some limited constant folding in the StackToRegisterMapingCogit. For example the pushTrue jumpFalse sequences generated in inlined and: and or: statements is eliminated. Also constant SmallInteger arithmetic is folded iff the receiver is a literal. The JIT doesn't have any type information so it can't fold var + 1 + 2, but it can and does fold 1 + 2 + var into 3 + var. Marcus Denker and I are working as I write on the infrastructure for an adaptive-optimizer/speculative-inliner that will initially operate at the bytecode level, deriving type information from the JIT's inline caches and using this to direct bytecode-to-bytecode optimization that will inline blocks, inline methods, etc. We hope eventually to target floating-point and other performance-critical code. Marcus posted a presentation I did a while back <Smalltalk Books Video Tutorials Smalltalk in Latam About Us! Contact Us Actually, I'm trying to make Ruby natural, not simple. -- Yukihiro "Matz" Matsumoto Home Talks & Presentations Eliot Miranda - Bytecode-to-bytecode adaptive optimization for Smalltalk Eliot Miranda - Bytecode-to-bytecode adaptive optimization for Smalltalk Last Updated (Sunday, 14 February 2010 20:21) | Written by Administrator | Monday, 18 August 2008 19:28 Multimedia Gallery - Talks & Presentations More ... Comments from the google video: This talk summarises two decades of work on Smalltalk and Self compilation and virtual machine technology and describes a novel attempt at an adaptive optimizer for Smalltalk that is written in Smalltalk and to a meaningful extent, portable across implementations. Smalltalk-80 and Self are fully object-oriented implicitly typed dynamic programming languages and interactive programming environments hosted above virtual machines that appear to execute stack-oriented bytecode for a pure stack machine. These systems' code and execution state are all represented by objects programmed in Smalltalk, such that the compiler, debugger, exception system and more are all implemented entirely in Smalltalk and available to the programmer for immediate incremental and interactive modification LikeDislike Community Disqus Add New Comment Optional: Login below. Post as … Showing 0 comments Sort by Subscribe by email Subscribe by RSS blog comments powered by DISQUS back to top < Prev Next > Main Menu Home ClubSmalltalk Merchandise About Us! Contact Us Articles Frontpage news Interviews Community ClubSmalltalk | Mailing List [In Spanish] ClubSmalltalk | LinkedIn Group ClubSmalltalk | Facebook ClubSmalltalk | Community Blogs Smalltalkers Blogs & Personal pages Smalltalkers - Social Network Environments Commercial Smalltalk Environments Free Smalltalk Environments Abbandon Smalltalk Environments Frameworks, Platforms & Tools FAQ Smalltalk Frequently Asked Questions GemStone Frequently Asked Questions ENVY/Manager Frequently Asked Questions Resources Smalltalk Jobs! Smalltalk Web Links Smalltalk News Feeds Smalltalk Books Smalltalk Podcasts Multimedia Gallery Back to the future - Photo Gallery Smalltalk History Channel Talks & Presentations Smalltalk Documentaries Login If you don't want to register in this site, you can use your Gmail or OpenId authentication. Username Password Remember Me Forgot your password? Forgot your username? Create an account Login with an OpenID What is OpenId? Smalltalk on Twitter J_WICKS_CTE (J.Wicks) : I hate 2 word sentences #smalltalk 11th_echo (Yvonne) : Da fand er unseren Smalltalk wohl so einlullend, dass er erstmal seine Schlüssel liegen ließ :DDDDDDDDDDDD höhö Dennis_Klinger (Dennis Klinger) : benachrichtigung bei antwort: hi leute ich hab mal ne frage. wie kann man sich benachrichtigen lassen wenn in ... http://bit.ly/gTytl0 onizee (Oneal Madumo) : Those who understnd #smalltalk ,guy walks in on me in th gym showers,and he says,"eish o tshwara shawara",how do i respond to this? JusCardo (Ricardo Cherry) : #SMALLtalk RT @_SweetTeee @JusCardo lol I hate you Paypal Donation Please, make a Paypal donation at least of 1 dollar! Thanks! Copyright © 2011 ClubSmalltalk. All Rights Reserved. Contact Us! Please, if you like the site visit our sponsors. Thanks.> that covers the essential ideas. This project could completely close the gap to C if augmented by a good quality code generator. At least, that's a goal. > -- jbthiel > >

4 6

reclamation cost of a fixed-size code zone
by Eliot Miranda 17 Feb '11

17 Feb '11

Hi All, with Marcus chez moi working together on adaptive optimization/speculative inlining Marcus wondered how big the Cog code zone is and how much time goes into reclamation. Reclamation is the process of throwing away some number of jitted methods to make room for methods that need to be jitted. Currently Cog's policy is hard-coded and it always throws away a quarter of the jitted methods, attempting to throw away the least-recenty used, based on a simple 3-bit usage count per method derived from marking methods on the stack and the methods they directly reference. On my 2.66 GHz Intel Core i7 Mac Book Pro the system seems to compact the code zone once every three or four seconds. Here is a more precise measurement for recompiling the world in my current development image. num compiled methods 93138 code size 1048576 compile all time (seconds) 48.48 compile all num compactions 20 compile all compaction period 2.42 milliseconds per compaction 0.85 percentage of runtime 0.035067 So a few things follow. A mere megabyte of code seems to be adequate; reclamation rates are low and the latency introduced is of the order of a youngSpace reclamation (I just measured an average of 0.825ms per young space collection in this image); the cost is extremely low, a mere 0.04% of entire execution time. (Note that the VM is using microsecond resolution times internally and answering totals in milliseconds). Here are the numbers repeated for a 2 megabyte code zone: num compiled methods 93138 code size 2097152 compile all time (seconds) 54.63 compile all num compactions 3 compile all compaction period 18.21 milliseconds per compaction 1.333 percentage of runtime 0.007322 So interestingly the overall runtime is higher, which could be because of poorer cache density due to the larger code zone and hence larger working set, the latency is a little higher (1.333 ms per compaction instead of 0.85) the rate of compactions and total cost is much lower. It would be interesting to measure costs for a range of code sizes for some realistic applications. But clearly a one megabyte code cache isn't that bad a choice. The code density advantages of a small working set could trump all other considerations. But of course much more thorough measurements would be required, for example variation in times could be being heavily influenced by the other programs I've got open at the moment. best, Eliot (| nbefore tbefore nafter tafter size ncm | nbefore := Smalltalk vmParameterAt: 62. tbefore := Smalltalk vmParameterAt: 63. ms := [Compiler recompileAll] timeToRun. nafter := Smalltalk vmParameterAt: 62. tafter := Smalltalk vmParameterAt: 63. size := Smalltalk vmParameterAt: 46. ncm := 0. SystemNavigation new allSelect: [:m| ncm := ncm + 1. false]. String new writeStream ensureCr; nextPutAll: 'num compiled methods '; print: ncm; cr; nextPutAll: 'code size '; print: size; cr; nextPutAll: 'compile all time (seconds) '; print: (ms / 1000 roundTo: 0.01); cr; nextPutAll: 'compile all num compactions '; print: nafter - nbefore; cr; nextPutAll: 'compile all compaction period '; print: (ms / 1000 / (nafter - nbefore) roundTo: 0.01); cr; nextPutAll: 'milliseconds per compaction '; print: ((tafter - tbefore) asFloat / (nafter - nbefore) roundTo: 0.001); cr; nextPutAll: 'percentage of runtime '; print: ((tafter - tbefore) * 100.0 / ms roundTo: 0.000001); cr; contents)

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Vm-dev February 2011