- Pharo-users - lists.pharo.org

Re: [Pharo-users] NativeBoost pointer and "+"

by Henrik Johansen

> On 09 Jun 2015, at 2:59 , Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > MyClass createCacheOf: data in: cache. Forgot to change this; you need to pass in the ExternalArray addresses as parameters, not the ExternalArrays themselves. MyClass createCacheOf: data address in: cache address Cheers, Henry

June 9, 2015

Re: [Pharo-users] NativeBoost pointer and "+"

by Henrik Johansen

There are many ways to Rome :) If you just need some externally allocated objects in the formats you specified you can do the cache extraction using nothing but normal Smalltalk: intArray := (NBExternalArray ofType: 'int'). data := intArray new: 1000. 1 to:data size do:[:i |data at:i put: i]. cache := intArray new: 50. 0 to: 4 do: [:j | 1 to: 10 do: [ :k | cache at: (j* 10) + k put: (data at: 199 + (30 * j ) + k)] ]. But if you want to take full advantage of the performance boost NB offers, you'd write a NativeBoost function to do the cache extraction*, as I outlined last time: MyClass class >> #createCacheOf: aSource in: aDestination createCacheOf: aSource in: aDestination <primitive: #primitiveNativeCall module: #NativeBoostPlugin> "Should work on both x86 and x64, as long as sizeOf: lookups work correctly" ^ self nbCallout function: #(void (int * aSource, int * aDestination) ) emit: [:gen :proxy :asm | |destReg srcReg tmpReg intSize ptrSize| intSize := NBExternalType sizeOf: 'int'. ptrSize := NBExternalType sizeOf: 'void *'. "Only use caller-saved regs, no preservation needed" destReg := asm EAX as: ptrSize. srcReg := asm ECX as: ptrSize. tmpReg := asm EDX as: intSize. asm pop: srcReg. asm pop: destReg. 0 to: 4 do: [ :j | 0 to: 9 do: [ :offset | asm "Displacement in bytes, not ptr element size :S, so we have to multiply offset by that manually :S" mov: tmpReg with: srcReg ptr + (199 + (j * 30) + offset * intSize); mov: destReg ptr + ((j* 10) + offset * intSize) with: tmpReg]]] and use that; intArray := (NBExternalArray ofType: 'int'). data := intArray new: 1000. 1 to:data size do:[:i |data at:i put: i]. cache := intArray new: 50. MyClass createCacheOf: data in: cache. The difference using a simple [] bench is about two orders of magnitude; 11million cache extractions per seconds for the inline assembly version, while the naive loop achieves around 110k. Cheers, Henry *as: is not yet defined, could be something like: AJx86GPRegister >> #as: aSize ^ self isHighByte ifTrue: [ self asLowByte as: aSize ] ifFalse: [ AJx86Registers generalPurposeWithIndex: self index size: aSize requiresRex: self index > (aSize > 1 ifTrue: [7] ifFalse: [ 3]) prohibitsRex: false ] > On 09 Jun 2015, at 9:46 , Matthieu Lacaton <matthieu.lacaton(a)gmail.com> wrote: > > Hello Henrik, > > Thank you very much for your answer. However, the code you provided is some sort of assembly right ? So does it mean that I need to learn assembly to do what I want ? > > I'm asking that because I don't know anything about assembly so it will take me some time to learn. > > Cheers, > > Matthieu > > 2015-06-08 19:56 GMT+02:00 Henrik Johansen <henrik.s.johansen(a)veloxit.no <mailto:henrik.s.johansen@veloxit.no>>: > > > On 08 Jun 2015, at 4:41 , Matthieu Lacaton <matthieu.lacaton(a)gmail.com <mailto:matthieu.lacaton@gmail.com>> wrote: > > > > Hello everyone, > > > > I have a small question about NativeBoost : How does the "+" operator when applied to a pointer translates into NativeBoost code ? > > > > To give a bit of context, what I want to do is to reallocate some non-contiguous bytes in memory to a buffer. Basically, I have an array of integers in a buffer and I want to copy some chunks of it in another buffer. The chunks are always the same size and the offset between each chunk is always the same too. > > > > Because a bit of actual code is easier to understand here is what I'd like to do in Pharo : > > > > ... > > > > int i, j; > > int *data = malloc(1000*sizeof(int)); > > int *newData = malloc(50*sizeof(int)); > > > > // Allocate initial data > > for (i = 0 ; i < 1000, i++) { > > data[i] = i; > > } > > > > //Copy desired chunks into new buffer > > for (i = 0; i < 5; i++ ) { > > memcpy( newData + j*10, data + 200 + j*30, 10*sizeof(int)); > > j++; > > } > > > > free(data); > > > > You can do relative addressing like this: > (destReg ptr: dataSize) + offsetReg + constant > > So with offSetRegs containing j* 10 and j* 30, you might end up with an unrolled inner loop (barring using any fancier longer-than-int moves) like: > > 0 to: 9 do: [:constantOffset | > asm mov: (destReg ptr: currentPlatform sizeOfInt) + dstOffsetReg + constantOffset with: (srcReg ptr: currentPlatform sizeOfInt) + 200 + srcOffsetReg + constantOffset] > > If the range of j is constant, you can just as easily unroll the whole thing in a similarly compact fashion, space and sensibilites permitting: > > 0 to: 4 do: [ :j | 0 to: 9 do: [ :consOffset | > asm mov: (destReg ptr: currentPlatform sizeOfInt) + (j* 10) + constOffset with: (srcReg ptr: currentPlatform sizeOfInt) + 200 + (j * 30) + constOffset] > > Cheers, > Henry >

June 9, 2015

Re: [Pharo-users] Fuel and graph update

by Mariano Martinez Peck

On Tue, Jun 9, 2015 at 9:21 AM, Hilaire <hilaire(a)drgeo.eu> wrote: > Hi, > > I want to use Fuel to persist a graph in file. > > The classic use case is "modify some part of the model and persist > immediately". > > Now, it is not really efficient to re-serialize the whole graph each > time, and I am wondering how you are approaching this particular point > when using Fuel as your persistence back-end. > > For example, various ideas coming to my mind: > - Is it possible to update some part of an already serialized graph? > - Should the graph be cut to pieces and serialized in several files? > - Or is Fuel fast enough to just re-serialize the whole graph? > > For Quuve app, when it runs on Pharo (for development and testing), we have a fuel backend and we do 2) and 3) of above. Quuve itself is split in different/isolated conceptual databases: clients, advisory, securities, system, application, etc. So each of them is a database. And yes, we have a fuel file per database and for each save we serialize the whole graph. You need to be careful about cross-references between databases.... Anyway, it works good enough for our scenario. Our database are around 5MB and the serialization is immediate. > How about you? > > Thanks > > Hilaire > > -- > Dr. Geo > http://drgeo.eu > http://google.com/+DrgeoEu > > > > -- Mariano http://marianopeck.wordpress.com

June 9, 2015

Fuel and graph update

by Hilaire

Hi, I want to use Fuel to persist a graph in file. The classic use case is "modify some part of the model and persist immediately". Now, it is not really efficient to re-serialize the whole graph each time, and I am wondering how you are approaching this particular point when using Fuel as your persistence back-end. For example, various ideas coming to my mind: - Is it possible to update some part of an already serialized graph? - Should the graph be cut to pieces and serialized in several files? - Or is Fuel fast enough to just re-serialize the whole graph? How about you? Thanks Hilaire -- Dr. Geo http://drgeo.eu http://google.com/+DrgeoEu

June 9, 2015

Re: [Pharo-users] NativeBoost pointer and "+"

by Matthieu Lacaton

Hello Henrik, Thank you very much for your answer. However, the code you provided is some sort of assembly right ? So does it mean that I need to learn assembly to do what I want ? I'm asking that because I don't know anything about assembly so it will take me some time to learn. Cheers, Matthieu 2015-06-08 19:56 GMT+02:00 Henrik Johansen <henrik.s.johansen(a)veloxit.no>: > > > On 08 Jun 2015, at 4:41 , Matthieu Lacaton <matthieu.lacaton(a)gmail.com> > wrote: > > > > Hello everyone, > > > > I have a small question about NativeBoost : How does the "+" operator > when applied to a pointer translates into NativeBoost code ? > > > > To give a bit of context, what I want to do is to reallocate some > non-contiguous bytes in memory to a buffer. Basically, I have an array of > integers in a buffer and I want to copy some chunks of it in another > buffer. The chunks are always the same size and the offset between each > chunk is always the same too. > > > > Because a bit of actual code is easier to understand here is what I'd > like to do in Pharo : > > > > ... > > > > int i, j; > > int *data = malloc(1000*sizeof(int)); > > int *newData = malloc(50*sizeof(int)); > > > > // Allocate initial data > > for (i = 0 ; i < 1000, i++) { > > data[i] = i; > > } > > > > //Copy desired chunks into new buffer > > for (i = 0; i < 5; i++ ) { > > memcpy( newData + j*10, data + 200 + j*30, 10*sizeof(int)); > > j++; > > } > > > > free(data); > > > > You can do relative addressing like this: > (destReg ptr: dataSize) + offsetReg + constant > > So with offSetRegs containing j* 10 and j* 30, you might end up with an > unrolled inner loop (barring using any fancier longer-than-int moves) like: > > 0 to: 9 do: [:constantOffset | > asm mov: (destReg ptr: currentPlatform sizeOfInt) + dstOffsetReg + > constantOffset with: (srcReg ptr: currentPlatform sizeOfInt) + 200 + > srcOffsetReg + constantOffset] > > If the range of j is constant, you can just as easily unroll the whole > thing in a similarly compact fashion, space and sensibilites permitting: > > 0 to: 4 do: [ :j | 0 to: 9 do: [ :consOffset | > asm mov: (destReg ptr: currentPlatform sizeOfInt) + (j* 10) + > constOffset with: (srcReg ptr: currentPlatform sizeOfInt) + 200 + (j * 30) > + constOffset] > > Cheers, > Henry >

June 9, 2015

Pharo sprint & Moose dojo this Friday

by Jean-Christophe Bach

Hello Pharoers, We propose a Pharo sprint / Moose dojo this Friday, 12th June, starting at 10:00am. (Local Time Lille). It will be at the Inria Lille, Building B, third floor (RMoD offices). Remotely, you can join us on the official IRC channel #pharo on irc.freenode.net server. During the sprint, we will try to synchronize local and remote Pharo sprinters. As the building is not open to the public, please contact us before if you plan to come. JC

June 9, 2015

Re: [Pharo-users] NativeBoost pointer and "+"

by Henrik Johansen

> On 08 Jun 2015, at 4:41 , Matthieu Lacaton <matthieu.lacaton(a)gmail.com> wrote: > > Hello everyone, > > I have a small question about NativeBoost : How does the "+" operator when applied to a pointer translates into NativeBoost code ? > > To give a bit of context, what I want to do is to reallocate some non-contiguous bytes in memory to a buffer. Basically, I have an array of integers in a buffer and I want to copy some chunks of it in another buffer. The chunks are always the same size and the offset between each chunk is always the same too. > > Because a bit of actual code is easier to understand here is what I'd like to do in Pharo : > > ... > > int i, j; > int *data = malloc(1000*sizeof(int)); > int *newData = malloc(50*sizeof(int)); > > // Allocate initial data > for (i = 0 ; i < 1000, i++) { > data[i] = i; > } > > //Copy desired chunks into new buffer > for (i = 0; i < 5; i++ ) { > memcpy( newData + j*10, data + 200 + j*30, 10*sizeof(int)); > j++; > } > > free(data); You can do relative addressing like this: (destReg ptr: dataSize) + offsetReg + constant So with offSetRegs containing j* 10 and j* 30, you might end up with an unrolled inner loop (barring using any fancier longer-than-int moves) like: 0 to: 9 do: [:constantOffset | asm mov: (destReg ptr: currentPlatform sizeOfInt) + dstOffsetReg + constantOffset with: (srcReg ptr: currentPlatform sizeOfInt) + 200 + srcOffsetReg + constantOffset] If the range of j is constant, you can just as easily unroll the whole thing in a similarly compact fashion, space and sensibilites permitting: 0 to: 4 do: [ :j | 0 to: 9 do: [ :consOffset | asm mov: (destReg ptr: currentPlatform sizeOfInt) + (j* 10) + constOffset with: (srcReg ptr: currentPlatform sizeOfInt) + 200 + (j * 30) + constOffset] Cheers, Henry

June 8, 2015

Re: [Pharo-users] Pharo on bitnami

by Mircea S.

Great!!! Contacted them myself too, with a contest entry for either Pharo stand-alone or Seaside on Pharo, since the contest mainly focuses on 'web frameworks'. For vanilla Pharo this was their response: "Thanks for your suggestion. Unfortunately we can not add Pharo in our Bitnami contest. We are currently focused on web applications and Pharo is a desktop IDE tool." So I added an entry on Seaside, which he has yet to reply to, adding examples on how to run headless cloud servers with that in mind: "I made another request for "Seaside" which is a Smalltalk (language) web framework that runs either on Pharo, GNU Smaltalk or other variants running headless, connecting remotely to add code or modify the app. For example a GNU Smalltalk: http://www.gnu.org/software/smalltalk/manual/html_node/Seaside.html Seaside apps, including the entire memory footprint is stored in an "image file", this image files acts like a miniVM virtual hard drive. When you save all objects are saved as the are, and when you load it again it essentially "resumes" exacly where it left off. Images are started this way and the app becomes available on a port, you can connect to it and "develop" de image and remotely write code and execute it inside like this: http://smalltalk.gnu.org/blog/bonzinip/seaside-development-gnu-smalltalk Seaside is used mainly in the financial industry and for heavy duty erp apps. Now it has gained a footprint in the community because of the advanced Object Oriented approach to web development with Seaside." He'll probably need more advice as things progress. You can reach David at david(a)bitnami.com Pe 7 iun. 2015, la 14:08, stepharo <stepharo(a)free.fr> a scris: > Hi pharoers > > we got in contact with bitnami and I would love to see two bitnami apps around Pharo: > - basic pharo > - pharo + seaside + magritte + voyage (mongo pharo layer) + mongodb > > So who would like to help pushing this effort? > > Stef > > Begin forwarded message: > > From: Kevin Franklin <kevin(a)bitnami.com> > Subject: Introducing Bitnami... > Date: 5 Jun 2015 10:57:36 GMT+2 > To: <board(a)pharo.org> > > Hello Pharo Association > > I wondered if you knew about Bitnami. Please check us out at www.bitnami.com. We provide over 120 apps and development stacks â many of them open-source. > If you would like Pharo to be included in our marketplace, we have a contest https://bitnami.com/contest were you can nominate it, and encourage your community to vote for its inclusion. > > Also, I wondered if you could put me in touch with any commercial companies within and around the Pharo ecosystem that might like to work with us as a software partner https://bitnami.com/partners/software > > Kind regards > Kevin > > -- > Kevin Franklin > Director of Business Development, Bitnami > +44 78 2525 6020 > @kevinjfranklin > > Run your favorite apps in the cloud with Bitnami > > Confidential - All Rights Reserved. > Bitnami Â© 2015 >

June 8, 2015

NativeBoost pointer and "+"

by Matthieu Lacaton

Hello everyone, I have a small question about NativeBoost : How does the "+" operator when applied to a pointer translates into NativeBoost code ? To give a bit of context, what I want to do is to reallocate some non-contiguous bytes in memory to a buffer. Basically, I have an array of integers in a buffer and I want to copy some chunks of it in another buffer. The chunks are always the same size and the offset between each chunk is always the same too. Because a bit of actual code is easier to understand here is what I'd like to do in Pharo : ... int i, j; int *data = malloc(1000*sizeof(int)); int *newData = malloc(50*sizeof(int)); // Allocate initial data for (i = 0 ; i < 1000, i++) { data[i] = i; } //Copy desired chunks into new buffer for (i = 0; i < 5; i++ ) { memcpy( newData + j*10, data + 200 + j*30, 10*sizeof(int)); j++; } free(data); ... Here basically I'll get in my buffer chunks of 10 integers starting at 200 with an offset of 30 between chunks, and this 5 times. (200 201 202 ... 208 209 230 231 ... 238 239 260 ... 328 329). I am okay with the malloc, memcpy and free but I don't know how to handle the "+" operator in my memcpy function. Thank you, Matthieu

June 8, 2015

Re: [Pharo-users] Bug in Open Workspace from File-Browser?

by Marcus Denker

Maybe use Smalltalk tools workspace instead of the direct referenceâ¦ In the long run, for GT, people will use the the FileList less and less and instead just use Spotter to explore the filesystem and then GT to look at filesâ¦ We should try to replace the FileList by Spotter for Pharo5â¦ less code to maintain. Marcus > On 07 Jun 2015, at 17:39, volkert <volkert(a)komponentenwerkstatt.de> wrote: > > I have found a bug and opened new case for it: https://pharo.fogbugz.com/f/cases/15711/ <https://pharo.fogbugz.com/f/cases/15711/> > I also what to send a fix. > But i am not sure, if the fix is as simple as i described it (see tail of this mail). > My Question: Is the bug in the UIManager or only on the sender FileList>>viewContentsInWorkspace. I think, in the sender. So i can simply replace "UIManager default edit: aString label: 'Workspace from ', self reference basename " with " Workspace openContents: aString label: 'Workspace from ', self reference basename". > > Am 07.06.2015 um 17:20 schrieb stepharo: >> UIManager was an attempt to support a way to theme widgets. >> And also to be able to run Pharo headless but providing a DummyManager. >> What is the original problem you faced? >> >> Stef >> >> >> Le 6/6/15 16:37, volkert a Ã©crit : >>> Is this change resonable. I have no idea, what the Design-Idea behind the UIManager what services is should provide. May be it make sense to have the extra services on UIManager, but think the bug is in FileList>>viewContentsInWorkspace and not in UIManager. >>> >>> ---- >>> I propose for Workspace to change the current code: >>> >>> FileList>>viewContentsInWorkspace >>> "View the contents of my selected file in a new workspace" >>> | aString | >>> self reference streamWritable: false do: [ :stream| >>> aString := stream setConverterForCode contentsOfEntireFile ]. >>> UIManager default edit: aString label: 'Workspace from ', self reference basename <----- WRONG >>> >>> to : >>> >>> FileList>>viewContentsInWorkspace >>> "View the contents of my selected file in a new workspace" >>> | aString | >>> self reference streamWritable: false do: [ :stream| >>> aString := stream setConverterForCode contentsOfEntireFile ]. >>> Workspace openContents: aString label: 'Workspace from ', self reference basename >>> >>> And i also proposse the add a Playground case. >>> >>> New Method: >>> >>> FileList>>viewContentsInPlayground >>> "View the contents of my selected file in a new playground" >>> | aString | >>> self reference streamWritable: false do: [ :stream| >>> aString := stream setConverterForCode contentsOfEntireFile ]. >>> GTPlayground openContents: aString label: 'Playground from ', self reference basename. >>> >>> and also FileList>>serviceViewContentsInPlayground and the case in ListList>>itemsForAnyFile. >>> >>> If ok, i can fix Workspace and add Playground menu to FileList, after i have figured out how to send an fix ;-) >>> >>> BW, >>> Volkert >>> >>> Am 03.06.2015 um 16:40 schrieb Ben Coman: >>>> Or do we now want such to open in Playground? >>>> >>>> btw, these are the relevant methods. >>>> FileList>>FileList>>viewContentsInWorkspace >>>> FileList>>viewContentsInWorkspace >>>> >>>> cheers -ben >>>> >>>> On Wed, Jun 3, 2015 at 6:57 PM, volkert <volkert(a)komponentenwerkstatt.de> <mailto:volkert@komponentenwerkstatt.de> wrote: >>>>> The File Browser has a Context Menu "Workspace with Contents". It opens an >>>>> Edit Window (String Morph), but not a Workspace ... >>>>> >>>>> Is the Menu-Title wrong or the implementation? >>>>> >>>>> BW, >>>>> Volkert >>>>> >>> >> >

June 8, 2015