- Pharo-dev - lists.pharo.org

Performance for Video Games(Woden Video)

by Ronie Salgado

I am working on making a video game engine in Pharo. Recently added a FPS counter and recorded some samples: http://youtu.be/-2ida5Q1mbg . Lets say I was quite surprised, so I have yet a lot more to optimize, but a good trick seems to be making some computation in the GPU. In this video, I show 6 early examples. The water example is still incomplete, missing reflection/refractions, but it shows what happens when I compute the water waves using a shader in the GPU. Please, pay a close attention to the FPS count. BTW, it feels slow because of the screen capture and the tearing is there because I haven't enabled vsync, but I have support for it. Greetings, Ronie Salgado

June 13, 2014

Spur Squeak Trunk Image Available

by Eliot Miranda

Hi All, it gives me great pleasure to let you know that a spur-format trunk Squeak image is finally available at http://www.mirandabanda.org/files/Cog/SpurImages/. Spur VMs are available at http://www.mirandabanda.org/files/Cog/VM/VM.r2987/. Spur is a new object representation and garbage collector for Squeak/Pharo/Croquet/Newspeak. Features The object representation is significantly simpler than the existing one, and hence permits a lot of JIT optimizations, in particular allocating objects in machine code. This speeds up new, new: et al, but also speeds up blocks because contexts and closures are now allocated in machine code. It also provides immediate characters, so for example accessing wide strings is much faster in Spur, since characters do not have to be instantiated to represent characters with codes greater than 255. The garbage collector has a scavenger and a global scan-mark-compact collector. The scavenger is significantly faster than the existing pointer-reversal scan-mark-compact, hence GC performance is much improved. The memory manager manages old space as a sequence of segments, as opposed to the single contiguous space provided by the existing memory manager. The memory manager grows the heap a segment at a time, and can and will release empty segments back to the host OS after a full GC. Hence Spur is able to grow the heap to the limit of available memory without one having to specify the VM's memory size at start-up. The object representation uses "lazy forwarding" to implement become:, creating copies of objects that are becommed, and forwarding the existing objects to the copies. While Spur still scans the stack zone on become to ensure no forwarding pointers to the receiver exist in stack frames (for check-free push and store instance variable operations), it does not scan the entire heap, catching sends to forwarded objects as part of the normal message send class checks, hence following forwarding pointers lazily, and eliminating forwarders during GC. The existing memory manager does a full memory sweep and compact to implement become. Hence Spur provides the performance advantages of direct pointers while providing a significantly faster become. While Spur uses moving GC (scavenging and compaction on full GC), just like the existing memory manager, Spur supports pinning, the ability to stop an object from moving. Old space objects will not be moved if pinned. Attempting to pin a new space object causes a become, forwarding the new space object to a pinned copy in old space. This allows simpler interfacing with foreign code through the FFI, since one can hand out references to pinned objects in the knowledge that they will not be moved by the GC. Finally Spur supports ephemerons in a simple and direct way, providing pre-mortem per-instance finalization. Although the image-level support needs to be written, it should soon be possible to improve the finalization of entities such as buffered files (ensuring they are flushed before being GCed), etc. Future Work Spur is as yet a work in progress. The 32-bit implementation is usable and appears stable. The major missing component is an incremental scan-mark GC that should eliminate long pauses due to the global scan-mark-compact GC (which is still invoked at snapshot time). I hope to start on this soon. But another key facet of Spur is that the object header format and the sizes of objects are common between 32- and 64-bits. In 32-bit and 64-bit Spur, object bodies are multiples of 8 bytes, so there may be an unused slot at the end of a 32-bit object with an odd number of slots. Hence Spur is close to providing a "true" 64-bit system, one with 61-bit SmallIntegers, and 61-bit SmallFloats (objects with the same precision, but less range that 64-bit Float, done by stealing bits from the exponent field). I look forward to collaborating with Esteban Lorenzano on 64-bit Spur and hope that it will be available early next year. Experience I am of course interested in reports of performance effects. Under certain, hopefully rare circumstances, Spur may actually be slower (one is when the number of processes involved in process switching exceeds the number of stack pages in the stack zone). But my limited experience is that Spur is significantly faster than the existing VM. Please post experiences, both positive and negative. Finally, caveat emptor! This is alpha code. Bugs may result in image corruption. If you do use Spur, please try and back up your work just in case. And if anything does go wrong please let me know, preferrably providing a reproducible case. Enjoy! Eliot Miranda

June 12, 2014

New Cog & Spur VMs available

by Eliot Miranda

see http://www.mirandabanda.org/files/Cog/VM/VM.r2987/ CogVM binaries as per VMMaker.oscog-eem.769/r2987 platform code: Type the memory allocators as accepting and answering usqInts to give a chance at allocating more than 2Gb. Use unsigned comparisons when testing if there's sufficient heap space in readImageFromFile:HeapSize:StartingAt:. Leads to accurate failure message when failing to allocate large heap. Correct syntax of inline assembler for byte and word swap operations in win32 16-bit displays. Thanks to Nicolai Hess! sqUnixX11.c: Include the right X11 include file to pull in the def for XK_equal (keysym.h vs keysymdef.h). Don't define BytesPerOop or BaseHeaderSize; these should be taken from interp.h. Integrate Philippe Back's fix for numberic keypads on X11; see https://pharo.fogbugz.com/f/cases/11352/. Add the XDisplayControlPlugin to the plugins loaded by the image build script. Use pthread_atfork to reinstall the heartbeat thread post fork. Make sure SIGALRM is unblocked if using the interval timer heartbeat on linux. Remove RPATH spec from unix builds. Include the executable name in the crash.dmp report. Fix stack backtrace printing on Mac & Unix to not segfault when invoked from error(char *msg) function. CoInterpreter: No longer inline CoInterpreter>>pre/postGCAction: for VM profiling. Fix instantiation of large non-byte objects. The old code for sufficientSpaceToInstantiate:indexableSize: stupidly subtracted BytesPerWord instead of ShiftForWord from LongSizeNumBits in determining the max size. Garbage collect/remap the primTraceLog correctly. If a GC happens very early in start-up the log circular buffer may not be full and the existing code assumed it always was. Add Spur-specific interpreter proxy functions for immediate character and pinning access. Implement the new Spur interpreterProxy API for ObjectMemory (of course pinObject: fails, and isCharacterValue: has a smaller range). Fix a bug in printing frame flags (order was the wrong way around). Allow vmParameterAt: 26 put: 0 to disable the heartbeat itimer. Add AioPlugin to Mac VMs. Make CoInterpreter>>printFrame: not mislead as to the number of temps in a block activation. Change the time primitives to access the time now, not the time as updated by the heartbeat (but /don't/ change the time basis for event checking. This for performance because use of gettimeofday in e.g. stack overflow can be a signficant performance overhead. Move the simulated time implementations (ioSeconds et al) up to StackInterpreter to reduce duplication. Add ioSecondsNow et al to the platform code to support this. Fix regression in primitiveUtcWithOffset, answer the correct local time offset. Fix ioSecondsNow to use the time now, not the heartbeat time. Revamp primitiveVMParameter to avoid overflow in values such as total heap size. Make statProcessSwitch, statIOProcessEvents, statForceInterruptCheck, statCheckForEvents, statStackOverflow & statStackPageDivorce 64-bit to avoid wrapping. Make sure that positive64BitIntegerFor: will not cause a GC just as positive32BitIntegerFor: doesn't. Make primitiveClone cope with variable args, cloning its last argument. This for the Newspeak VMMirror. Add primitiveAllObjects, adapted from VMMaker-dtl.339.mcz Add Nicolas Cellier's bitblt speedups, reference: Mantis issue 7802: Fast-up BitBlt rgbAdd rule Mantis issue 7803: Fast-up BitBlt alpha blending rules Check for valid bitmap in primitivePixelValueAt aka BitBltSimulation>> primitivePixelValueAtX:y: Fix provided by Nicolas Cellier. Reference Mantis 7799 Avoid including the instructionPointer in the context when marrying the top frame during divorceAllFrames for voidVMState..If:. (how did this ever work??) Fix a bug in BitBltPlugin>>lockSurfaces. Add the compression prims to the Newspeak VM's ZipPlugin. Fix roomToPushNArgs:; the Cog VMs can be more lenient because of the use of a stack instead of contexts. Fixes some valueWithArguments: failures. Integrate Nice's improved SmallInteger generated primitives that support int x float comparison, & hence speed-up int x float comparison enormously. Integrate VMMaker-dtl.328 (failure of primitiveDisplayString to advance destX). Integrate 2792, fix memory leaks in SqueakSSL on unix. Integrate VMMaker-tpr.325 7247: BitBlt Bug in alphaSourceBlendBits8. Integrate VMMaker-tpr.326, Fix a single-bit constant error in BitBltSimulation>>copyBits:Fallback: - change 16r3FFF to 16r7FFF to correct tallyIntoMap behaviour for Scratch using BenBlt on the Pi. Restrict at-cache to bytecodePrimAt[Put], eliminating it from primitive[String]At[Put]. Sionara the explicit noAtCache at:[put:] machinery in CoInterpreter now that the atCache is confined to the interpreter's special selector at:[put:] bytecodes. Speeds up Stack VM signfiicantly, e.g. a compile of Compiler package falls from 1.6s to 1.4s on 2.2GHz Intel Core i7 MacBook Pro. Restrict at-cache to bytecodePrimAt[Put], eliminating it from primitive[String] At[Put]. Undoes need for fix in VMMaker-oscog.44 of 7 January 2011: "Fix leaking of objects into the atCache due to ceSend:super:to:numArgs:'s use of executeNewMethod without always setting messageSelector." This renders messageSelector and lkupClass ephemeral, since they are live only during message lookup and because createActualMessageTo will not cause a GC these cannot change during message lookup. Hence eliminate them from markAndTraceInterpreterOops: & mapVMRegisters. Fix arg count for primPCREExecfromto Cogit: Streamline the genPrimReturnEnterCogCodeEnilopmart. Streamline genExternalizePointersForPrimitiveCall Have StackToRegisterMappingCogit>>genPushReceiverBytecode use ReceiverResultReg if it contains self. Fix a double free bug in unlinkSendsOf:isMNUSelector:. Harmless cuz the result is only a bogus count of how many methods freed. Beef up the cog method integrity check to verify a its methodObject is a CompiledMethod. Fix bug in unlinkSendsOf:isMNUSelector: (primitiveFlushCacheBySelector) where old code could free the method of an active frame. Fix an assert fail in mapFor:bcpc:performUntil:arg: (this for primitiveClass where the class table reference can be the first map entry). Fix a bug in Newspeak remapIfObjectRef:pc:hasYoung: with dynamic super sends which could compute an invalid target method. Rename pushExplicitOuterSendReceiverBytecode et al to pushExplicitOuterReceiverBytecode et al. These are not sends. Fix pc-mapping for NewspeakV4. Dynamic super sends should /not/ be annotated with IsNSSendCall, but wth the vanilla IsSendCall. This fixes a bug converting an interpreter activation of a method with a loop and a dynamic super send to a machine code frame. For performance, specify that mapFor:[bcpc:]performUntil:arg: are inlined, eliminating the perform/indirect function call. This adds of the order of 3% to the size of a cogit.o's text seg so is acceptable. Print (nil) next to the selector for cog methods with a nil selector. Fix bug in Cogit>>unlinkSendsOf:isMNUSelector:, used by primitiveFlushCacheBySelector. The method could leave sends linked to freed MNU PICs. -- best, Eliot

June 12, 2014

Smalltalker wanted ! Job opening for Cincom ChannelStream

by stepharo

Hi guys this may help some of you. Apparently some people do not realize that they may find smalltalkers in this mailing-list but I'm happy that they are looking for somebody. Stef Begin forwarded message: From: "Nowak, Helge" <HNowak(a)cincom.com> Subject: [vwnc] Smalltalker wanted ! Job opening for Cincom ChannelStream Date: 11 Jun 2014 15:46:13 GMT+2 To: VW NC <vwnc(a)cs.uiuc.edu> Dear Smalltalkers! Weâre hiring! Cincom is looking for an experienced Smalltalker, a SOFTWARE ENGINEER. Our new colleague shall strengthen the development team for our document output product Cincom ChannelStream (developed in Cincom Smalltalk). Applications are accepted until the position is filled. Â· English: http://documentoutput.cincom.com/software-engineer-cincom-channelstream/ Â· French:http://documentoutput.cincom.fr/2014/06/opportunite-software-engineer-cincom-channelstream/ Cheers Helge P. S. wonder what ChannelStream is? Itâs Document Output Made Simple! Look here: http://documentoutput.cincom.com/

June 12, 2014

Re: [Pharo-dev] pharo-contribution ci dead?

by Yuriy Tymchuk

thank you! On 12 Jun 2014, at 17:55, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On 12 Jun 2014, at 17:43, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > >> Hi guys, does anybody know about what is happening with pharo-contribution jenkins? I mean, it definitely looks dead, but are there any expectations for recoverage? >> > > strangeâ¦ I have restarted it. > > Marcus

June 12, 2014

Re: [Pharo-dev] news from block :)

by Esteban Lorenzano

On 12 Jun 2014, at 12:53, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On 12 Jun 2014, at 16:06, stepharo <stepharo(a)free.fr> wrote: > >>> I like the idea. The current Morph classes are too big. It is >>> difficult to understand them and to find out how to work with them >>> "the right way" (event handling for example or layouting). >>> >>> Can you describe something more about the design. Or is the design >>> a work in progress. >>> >>> Please, I hope the "properties"-Dictionary is only a left over for >>> Morphic compatibility. I never understood why these are >>> used instead of proper selector and objects representing actual >>> properties. >>> >> For some objects you need a hashtable-based object because you may need a property that >> does not make sense all the time or just for some kinds of objects. >> So the extension is not a bad idea per se but we should pay attention. >> > > The PropertySlots will be interesting for thisâ¦ the real negative point of properties as used > in Morhpic is that they do not need to be declared. With property slots, you get the same > memory efficiency, but you are forced to declare that a proper is used. Yeah, but I would not inflate the base morph with something that I might or might not use. I would use a hierarchy instead. Esteban > > Marcus > >

June 12, 2014

Re: [Pharo-dev] pharo-contribution ci dead?

by Marcus Denker

On 12 Jun 2014, at 17:43, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > Hi guys, does anybody know about what is happening with pharo-contribution jenkins? I mean, it definitely looks dead, but are there any expectations for recoverage? > strangeâ¦ I have restarted it. Marcus

June 12, 2014

Re: [Pharo-dev] news from block :)

by Marcus Denker

On 12 Jun 2014, at 16:06, stepharo <stepharo(a)free.fr> wrote: >> I like the idea. The current Morph classes are too big. It is >> difficult to understand them and to find out how to work with them >> "the right way" (event handling for example or layouting). >> >> Can you describe something more about the design. Or is the design >> a work in progress. >> >> Please, I hope the "properties"-Dictionary is only a left over for >> Morphic compatibility. I never understood why these are >> used instead of proper selector and objects representing actual >> properties. >> > For some objects you need a hashtable-based object because you may need a property that > does not make sense all the time or just for some kinds of objects. > So the extension is not a bad idea per se but we should pay attention. > The PropertySlots will be interesting for thisâ¦ the real negative point of properties as used in Morhpic is that they do not need to be declared. With property slots, you get the same memory efficiency, but you are forced to declare that a proper is used. Marcus

June 12, 2014

pharo-contribution ci dead?

by Yuriy Tymchuk

Hi guys, does anybody know about what is happening with pharo-contribution jenkins? I mean, it definitely looks dead, but are there any expectations for recoverage?

June 12, 2014

Re: [Pharo-dev] news from block :)

by stepharo

On 11/6/14 22:33, kilon alios wrote: > well if you keep the overall design of morphic or even improve it. I > have no complain and you have my full support. I thought that you > wanted to remove Morphic and make Spec the standard design for Pharo. > I know what neither Athens or Roassal is a replacement for Morphic. you confuse layers. Athens is an API to draw on a screen. Morphic is a graphics framework. Spec is a ui builder to compose widgets out of smaller widgets. > I remember once I took a look at TreeMorph and I was shaking my head > with sadness, it was really bad :D So yes Morphic is very messy. TreeMorph is just a widget that grows organically. > I also don't claim, just for the record, that the above libraries are > not very useful and that I am not happy that are around and I can use > them. I really appreciate people hard work and I am definitely try to > learn as much as my limited free time allows me to. > > Maybe if you sit down and build a roadmap on the direction you want to > go as a community on the GUI front this will help people contribute as > it will set a clear goal for them. > > > On Wed, Jun 11, 2014 at 11:25 PM, Esteban Lorenzano > <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: > > > On 11 Jun 2014, at 17:15, kilon alios <kilon.alios(a)gmail.com > <mailto:kilon.alios@gmail.com>> wrote: > >> Yes personally I really like the overall design of a morph >> embedding nice and easily inside another morph and everything >> made up of morphs. I like the idea of hand , world , etc. >> >> I try to like Spec, but it looks to me quite confusing, I tried >> to follow the tutorial but I cant understand its design and why >> so many methods are needed to setup a spec widget. I also dislike >> the use or pragmas. I will continue learning it but I don't >> prefer it over Morphic for now. AFAIK apart from Spec and >> Morphic there is no other choice. > > Spec is not an alternative to Morphic, is a superset (a way to > nicely build widget components). > So apart from *Morphic*, you do not have any other choice :) > >> >> I also have hard time understanding Roassal and Athens. With >> Morphic its hard at times to figure out whats going on but at >> least it took very little time to understand the overall design. > > Same here. None of them are replacementsâ¦ is a framework for > visualisations (in the case of Roassal) and a framework for > drawing (in case of Athens). One is on top of Morphic and the > other is below it (you can do morphs that are drawn with Athens). > >> >> I don't have a problem with Pharo abandoning Morphic. Afterally >> you all use Pharo far more than I do. I will continue learning >> Spec, Roassal and Athens. But for me Morphic is the most >> beautiful Graphics API I have ever worked with. > > We are not moving out from Morphic any time soon. > Also, moving from an implementation of Morphic does not means we > are going to refuse his general design or all the cool experience > we accumulated in the time. > Think on morphic and block like with Battlestar Galactica from > 1978 and 2003: Same general design, but a complete âre-imaginedâ > taking with us all we learned in the mean time :) > >> >> >> On Wed, Jun 11, 2014 at 10:55 PM, Esteban Lorenzano >> <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: >> >> >> On 11 Jun 2014, at 16:39, kilon alios <kilon.alios(a)gmail.com >> <mailto:kilon.alios@gmail.com>> wrote: >> >>> excellent news. I really believe in Morphic and I really >>> like its general design. If you we can clean the mud I am >>> sure we will discover quite a diamond underneath. Thanks. >> >> which general design? the pattern in which is based? thatâs >> not enough to keep it :) >> Sorry but there is no easy/efficient way to clean it. >> The only way to clean Morphic is to reimplement it. >> Clean it is just too much workâ¦ and too many design decisions >> where made that time and patches made them obsolete or not >> correct. >> Not to talk about the mix of concepts (bah, the no existence >> of separation between them). >> >> Block is not a clean. Is a revamp. >> >> No offence intended to Morphic: no matter how good was at the >> beginning, *every* system evolves up to a point the effort >> required to maintain it is superior to the effort required to >> reimplement it (with all the experience as a superior step). >> (yeah, yeahâ¦ a lot of people will disagree. But time has >> proven me rightâ¦ and will continue doing it :P) >> >> Esteban >> >>> >>> >>> On Wed, Jun 11, 2014 at 10:25 PM, FranÃ§ois Stephany >>> <tulipe.moutarde(a)gmail.com >>> <mailto:tulipe.moutarde@gmail.com>> wrote: >>> >>> \o/ >>> >>> >>> On Wed, Jun 11, 2014 at 4:23 PM, Camille Teruel >>> <camille.teruel(a)gmail.com >>> <mailto:camille.teruel@gmail.com>> wrote: >>> >>> >>> On 11 juin 2014, at 15:31, FranÃ§ois Stephany >>> <tulipe.moutarde(a)gmail.com >>> <mailto:tulipe.moutarde@gmail.com>> wrote: >>> >>>> What is bloc ? >>>> I've searched in the pharo-dev list but couldn't >>>> find it :/ >>> >>> A Morphic clean/revamp lead by Alain and Stef. >>> >>>> >>>> On Wed, Jun 11, 2014 at 2:26 PM, stepharo >>>> <stepharo(a)free.fr <mailto:stepharo@free.fr>> wrote: >>>> >>>> looks so exciting... >>>> >>>> From: Alain Plantec >>>> <alain.plantec(a)univ-brest.fr >>>> <mailto:alain.plantec@univ-brest.fr>> >>>> Subject: Bloc news >>>> Date: 11 Jun 2014 14:10:29 GMT+2 >>>> To: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr >>>> <mailto:stephane.ducasse@inria.fr>> >>>> Cc: Alain Plantec <alain.plantec(a)univ-brest.fr >>>> <mailto:alain.plantec@univ-brest.fr>> >>>> >>>> Name: Bloc-Core-AlainPlantec.15 >>>> Author: AlainPlantec >>>> Time: 11 June 2014, 2:07:16.813171 pm >>>> UUID: d58ae82e-b5dd-41d9-bc31-a48c3e9e5cf1 >>>> Ancestors: Bloc-Core-AlainPlantec.14 >>>> >>>> - BlMorphs manage their submorphs with local >>>> coordinate. >>>> - Drawing and drag&drop has been adapted to >>>> local coordinate >>>> - Consequence: TransformationMorph should not >>>> be useful anymore because each morph has its >>>> own transform (not only TransformationMorph). >>>> Each morph uses its own transform to declare >>>> changed portions of its bounds and to draw its >>>> submorphs. >>>> - The world is no more a special morph: >>>> - the hand is owned by the space >>>> - the canvas and the display/redisplay of >>>> morphs are space responsibilities. >>>> This open the door to several worlds per space. >>>> >>>> Now the current global redrawing mechanism >>>> efficiency is not obvious. >>>> Next actions: >>>> - try to localize as much as possible the >>>> redrawing of morphs, >>>> - dig several Worlds for a space >>>> - start to comment and write a separate >>>> documentation with the help of Stephane :) >>>> >>>> >>>> >>> >>> >>> >> >> > >

June 12, 2014