Accelerating LargeIntegersPlugin phase 2
Locked
Accelerating LargeIntegersPlugin phase 2
 
|
I published code on SmalltalkHub (nice occasion to test it, and I did not want to pollute source.squeak.org with experimental) in sync with .oscog branch. MCHttpRepository location: 'http://smalltalkhub.com/mc/nice/NiceVMExperiments/main' user: 'nice' password: '' I also blogged about it http://smallissimo.blogspot.fr/2013/01/update-on-squeak-largeinteger-32-bits.html I didn't take any care to make the code 64bits friendly. This will require a review... Nicolas |
Re: Accelerating LargeIntegersPlugin phase 2
|
|
I've now added support for BigEndian machine to LargeIntegersPlugin v2.0 (32 bits digits) On such machine, LargeIntegers (Positive or Negative) will be stored in big-endian (native) 32 bits words. If course, images will be saved with that peculiar byteOrder by a new VM. I used bit 7 (1<<6=64) of image headerFlags to flag the peculiarity. Eliot, let me know if you have bigger plan for that bit, and if so, please assign another one to my experiments. It will be easy to add reverse support to make an image readable by an old VM, if ever... Of course, I've got no such BigEndian machine. So it's up to a good soul to test it for me... (or a CI machine?) To produce a StackInterpreter VM, load VMMaker.oscog-nice.275 from the SmalltalkHub repository, then follow usual cog svn branch instructions to generate, compile, ... Before using the new VM on a BigEndian machine, a pre-requisite is to load/merge Kernel-nice.734 because it contains a definitions of #digitAt: #digitAt:put: and #digitLength compatible across different VM. There might be some nasty side effect if you try to copy LargeInt<->ByteArray with available primitives (I know some packages do it). When we are cheating (by letting LargeInt variable-byte) there must be a price to pay... Maybe I'll try to address this known limitation later. That's all for now, my VM hacking are mostly late-night, and I need a little rest. Let me know if you ever try the adventure of using dangerous early hour coding ;) Nicolas 2013/1/19 Nicolas Cellier <[hidden email]>: > I published code on SmalltalkHub (nice occasion to test it, and I did > not want to pollute source.squeak.org with experimental) in sync with > .oscog branch. > MCHttpRepository > location: 'http://smalltalkhub.com/mc/nice/NiceVMExperiments/main' > user: 'nice' > password: '' > > I also blogged about it > http://smallissimo.blogspot.fr/2013/01/update-on-squeak-largeinteger-32-bits.html > > I didn't take any care to make the code 64bits friendly. This will > require a review... > > Nicolas |
Re: Accelerating LargeIntegersPlugin phase 2
|
|
Nicolas if you want we can set up a jenkins build for your code. We have all the machines and it costs us so much energy but it is really starting to pay back. Just ask. The inria service will get out of beta 24 of january. Stef On Jan 19, 2013, at 11:40 PM, Nicolas Cellier wrote: > > I've now added support for BigEndian machine to LargeIntegersPlugin > v2.0 (32 bits digits) > On such machine, LargeIntegers (Positive or Negative) will be stored > in big-endian (native) 32 bits words. > If course, images will be saved with that peculiar byteOrder by a new VM. > I used bit 7 (1<<6=64) of image headerFlags to flag the peculiarity. > Eliot, let me know if you have bigger plan for that bit, and if so, > please assign another one to my experiments. > It will be easy to add reverse support to make an image readable by an > old VM, if ever... > > Of course, I've got no such BigEndian machine. > So it's up to a good soul to test it for me... (or a CI machine?) > To produce a StackInterpreter VM, load VMMaker.oscog-nice.275 from the > SmalltalkHub repository, then follow usual cog svn branch instructions > to generate, compile, ... > > Before using the new VM on a BigEndian machine, a pre-requisite is to > load/merge Kernel-nice.734 because it contains a definitions of > #digitAt: #digitAt:put: and #digitLength compatible across different > VM. > > There might be some nasty side effect if you try to copy > LargeInt<->ByteArray with available primitives (I know some packages > do it). When we are cheating (by letting LargeInt variable-byte) there > must be a price to pay... Maybe I'll try to address this known > limitation later. > > That's all for now, my VM hacking are mostly late-night, and I need a > little rest. > Let me know if you ever try the adventure of using dangerous early > hour coding ;) > > Nicolas > > 2013/1/19 Nicolas Cellier <[hidden email]>: >> I published code on SmalltalkHub (nice occasion to test it, and I did >> not want to pollute source.squeak.org with experimental) in sync with >> .oscog branch. >> MCHttpRepository >> location: 'http://smalltalkhub.com/mc/nice/NiceVMExperiments/main' >> user: 'nice' >> password: '' >> >> I also blogged about it >> http://smallissimo.blogspot.fr/2013/01/update-on-squeak-largeinteger-32-bits.html >> >> I didn't take any care to make the code 64bits friendly. This will >> require a review... >> >> Nicolas |
Re: Accelerating LargeIntegersPlugin phase 2
|
|
Hi Steph, thanks, I think this might be usefull. These experiments were carried alone without any form of coordination. So, to not waste too much energy, the first step is to get some kind of blessing from Eliot. If he is OK and we have a chance of integrating the changes back in COG, then we can start testing. Nicolas 2013/1/20 stephane ducasse <[hidden email]>: > > Nicolas > > if you want we can set up a jenkins build for your code. We have all the machines and > it costs us so much energy but it is really starting to pay back. > Just ask. > The inria service will get out of beta 24 of january. > > Stef > > On Jan 19, 2013, at 11:40 PM, Nicolas Cellier wrote: > >> >> I've now added support for BigEndian machine to LargeIntegersPlugin >> v2.0 (32 bits digits) >> On such machine, LargeIntegers (Positive or Negative) will be stored >> in big-endian (native) 32 bits words. >> If course, images will be saved with that peculiar byteOrder by a new VM. >> I used bit 7 (1<<6=64) of image headerFlags to flag the peculiarity. >> Eliot, let me know if you have bigger plan for that bit, and if so, >> please assign another one to my experiments. >> It will be easy to add reverse support to make an image readable by an >> old VM, if ever... >> >> Of course, I've got no such BigEndian machine. >> So it's up to a good soul to test it for me... (or a CI machine?) >> To produce a StackInterpreter VM, load VMMaker.oscog-nice.275 from the >> SmalltalkHub repository, then follow usual cog svn branch instructions >> to generate, compile, ... >> >> Before using the new VM on a BigEndian machine, a pre-requisite is to >> load/merge Kernel-nice.734 because it contains a definitions of >> #digitAt: #digitAt:put: and #digitLength compatible across different >> VM. >> >> There might be some nasty side effect if you try to copy >> LargeInt<->ByteArray with available primitives (I know some packages >> do it). When we are cheating (by letting LargeInt variable-byte) there >> must be a price to pay... Maybe I'll try to address this known >> limitation later. >> >> That's all for now, my VM hacking are mostly late-night, and I need a >> little rest. >> Let me know if you ever try the adventure of using dangerous early >> hour coding ;) >> >> Nicolas >> >> 2013/1/19 Nicolas Cellier <[hidden email]>: >>> I published code on SmalltalkHub (nice occasion to test it, and I did >>> not want to pollute source.squeak.org with experimental) in sync with >>> .oscog branch. >>> MCHttpRepository >>> location: 'http://smalltalkhub.com/mc/nice/NiceVMExperiments/main' >>> user: 'nice' >>> password: '' >>> >>> I also blogged about it >>> http://smallissimo.blogspot.fr/2013/01/update-on-squeak-largeinteger-32-bits.html >>> >>> I didn't take any care to make the code 64bits friendly. This will >>> require a review... >>> >>> Nicolas > |
Re: Accelerating LargeIntegersPlugin phase 2
|
|
On Jan 20, 2013, at 11:19 AM, Nicolas Cellier wrote: > > Hi Steph, > thanks, I think this might be usefull. > These experiments were carried alone without any form of coordination. > So, to not waste too much energy, the first step is to get some kind > of blessing from Eliot. > If he is OK and we have a chance of integrating the changes back in > COG, then we can start testing. Ok Just do not hesitate, the guys here will help. Git you can hack in your own connected with a jenkins build with green tests and people can cherry pick what they want. We are preparing the following set up: - official pharo jenkins builds for VM and images (as few as possible) - experimental build for … work under way/experiment…. - … We really want to support people to focus on the right place and not spend their time on scripts and other infrastructure tasks that can be fully automatized. Stef > > Nicolas > > 2013/1/20 stephane ducasse <[hidden email]>: >> >> Nicolas >> >> if you want we can set up a jenkins build for your code. We have all the machines and >> it costs us so much energy but it is really starting to pay back. >> Just ask. >> The inria service will get out of beta 24 of january. >> >> Stef >> >> On Jan 19, 2013, at 11:40 PM, Nicolas Cellier wrote: >> >>> >>> I've now added support for BigEndian machine to LargeIntegersPlugin >>> v2.0 (32 bits digits) >>> On such machine, LargeIntegers (Positive or Negative) will be stored >>> in big-endian (native) 32 bits words. >>> If course, images will be saved with that peculiar byteOrder by a new VM. >>> I used bit 7 (1<<6=64) of image headerFlags to flag the peculiarity. >>> Eliot, let me know if you have bigger plan for that bit, and if so, >>> please assign another one to my experiments. >>> It will be easy to add reverse support to make an image readable by an >>> old VM, if ever... >>> >>> Of course, I've got no such BigEndian machine. >>> So it's up to a good soul to test it for me... (or a CI machine?) >>> To produce a StackInterpreter VM, load VMMaker.oscog-nice.275 from the >>> SmalltalkHub repository, then follow usual cog svn branch instructions >>> to generate, compile, ... >>> >>> Before using the new VM on a BigEndian machine, a pre-requisite is to >>> load/merge Kernel-nice.734 because it contains a definitions of >>> #digitAt: #digitAt:put: and #digitLength compatible across different >>> VM. >>> >>> There might be some nasty side effect if you try to copy >>> LargeInt<->ByteArray with available primitives (I know some packages >>> do it). When we are cheating (by letting LargeInt variable-byte) there >>> must be a price to pay... Maybe I'll try to address this known >>> limitation later. >>> >>> That's all for now, my VM hacking are mostly late-night, and I need a >>> little rest. >>> Let me know if you ever try the adventure of using dangerous early >>> hour coding ;) >>> >>> Nicolas >>> >>> 2013/1/19 Nicolas Cellier <[hidden email]>: >>>> I published code on SmalltalkHub (nice occasion to test it, and I did >>>> not want to pollute source.squeak.org with experimental) in sync with >>>> .oscog branch. >>>> MCHttpRepository >>>> location: 'http://smalltalkhub.com/mc/nice/NiceVMExperiments/main' >>>> user: 'nice' >>>> password: '' >>>> >>>> I also blogged about it >>>> http://smallissimo.blogspot.fr/2013/01/update-on-squeak-largeinteger-32-bits.html >>>> >>>> I didn't take any care to make the code 64bits friendly. This will >>>> require a review... >>>> >>>> Nicolas >> |
Re: Accelerating LargeIntegersPlugin phase 2
|
|
In reply to this post by Nicolas Cellier
I'll mention also that, although much work remains to be done in merging oscog and trunk VM code bases, I think that overall we are doing very well with the primitives. The VM primitives are now almost all in class InterpreterPrimitives, and changes can easily by adopted in both branches. Likewise, the plugins such as LargeIntegersPlugin can easily be kept in sync in the two branches. That means that changes like these can be tested and adopted in either branch at the convenience of the person doing the work. I'm doing my best to pick up changes as they are added to Cog, and Eliot is doing likewise with changes that show up first in the interpreter VM. I don't happen to have a big endian machine, but hopefully someone else has one and can help out with the testing, using either an interpreter VM or Cog VM. Dave On Sun, Jan 20, 2013 at 11:19:00AM +0100, Nicolas Cellier wrote: > > Hi Steph, > thanks, I think this might be usefull. > These experiments were carried alone without any form of coordination. > So, to not waste too much energy, the first step is to get some kind > of blessing from Eliot. > If he is OK and we have a chance of integrating the changes back in > COG, then we can start testing. > > Nicolas > > 2013/1/20 stephane ducasse <[hidden email]>: > > > > Nicolas > > > > if you want we can set up a jenkins build for your code. We have all the machines and > > it costs us so much energy but it is really starting to pay back. > > Just ask. > > The inria service will get out of beta 24 of january. > > > > Stef > > > > On Jan 19, 2013, at 11:40 PM, Nicolas Cellier wrote: > > > >> > >> I've now added support for BigEndian machine to LargeIntegersPlugin > >> v2.0 (32 bits digits) > >> On such machine, LargeIntegers (Positive or Negative) will be stored > >> in big-endian (native) 32 bits words. > >> If course, images will be saved with that peculiar byteOrder by a new VM. > >> I used bit 7 (1<<6=64) of image headerFlags to flag the peculiarity. > >> Eliot, let me know if you have bigger plan for that bit, and if so, > >> please assign another one to my experiments. > >> It will be easy to add reverse support to make an image readable by an > >> old VM, if ever... > >> > >> Of course, I've got no such BigEndian machine. > >> So it's up to a good soul to test it for me... (or a CI machine?) > >> To produce a StackInterpreter VM, load VMMaker.oscog-nice.275 from the > >> SmalltalkHub repository, then follow usual cog svn branch instructions > >> to generate, compile, ... > >> > >> Before using the new VM on a BigEndian machine, a pre-requisite is to > >> load/merge Kernel-nice.734 because it contains a definitions of > >> #digitAt: #digitAt:put: and #digitLength compatible across different > >> VM. > >> > >> There might be some nasty side effect if you try to copy > >> LargeInt<->ByteArray with available primitives (I know some packages > >> do it). When we are cheating (by letting LargeInt variable-byte) there > >> must be a price to pay... Maybe I'll try to address this known > >> limitation later. > >> > >> That's all for now, my VM hacking are mostly late-night, and I need a > >> little rest. > >> Let me know if you ever try the adventure of using dangerous early > >> hour coding ;) > >> > >> Nicolas > >> > >> 2013/1/19 Nicolas Cellier <[hidden email]>: > >>> I published code on SmalltalkHub (nice occasion to test it, and I did > >>> not want to pollute source.squeak.org with experimental) in sync with > >>> .oscog branch. > >>> MCHttpRepository > >>> location: 'http://smalltalkhub.com/mc/nice/NiceVMExperiments/main' > >>> user: 'nice' > >>> password: '' > >>> > >>> I also blogged about it > >>> http://smallissimo.blogspot.fr/2013/01/update-on-squeak-largeinteger-32-bits.html > >>> > >>> I didn't take any care to make the code 64bits friendly. This will > >>> require a review... > >>> > >>> Nicolas > > |
Re: Accelerating LargeIntegersPlugin phase 2
|
|
On 20 January 2013 15:37, David T. Lewis <[hidden email]> wrote: > > I'll mention also that, although much work remains to be done in merging > oscog and trunk VM code bases, I think that overall we are doing very > well with the primitives. The VM primitives are now almost all in class > InterpreterPrimitives, and changes can easily by adopted in both branches. > Likewise, the plugins such as LargeIntegersPlugin can easily be kept in > sync in the two branches. > > That means that changes like these can be tested and adopted in either > branch at the convenience of the person doing the work. I'm doing my > best to pick up changes as they are added to Cog, and Eliot is doing > likewise with changes that show up first in the interpreter VM. > > I don't happen to have a big endian machine, but hopefully someone else > has one and can help out with the testing, using either an interpreter > VM or Cog VM. At the risk of sounding rather ignorant, what kind of machine would that be? IIRC the 68k machines were big endian but they've been wiped out now haven't they? frank > Dave > > On Sun, Jan 20, 2013 at 11:19:00AM +0100, Nicolas Cellier wrote: >> >> Hi Steph, >> thanks, I think this might be usefull. >> These experiments were carried alone without any form of coordination. >> So, to not waste too much energy, the first step is to get some kind >> of blessing from Eliot. >> If he is OK and we have a chance of integrating the changes back in >> COG, then we can start testing. >> >> Nicolas >> >> 2013/1/20 stephane ducasse <[hidden email]>: >> > >> > Nicolas >> > >> > if you want we can set up a jenkins build for your code. We have all the machines and >> > it costs us so much energy but it is really starting to pay back. >> > Just ask. >> > The inria service will get out of beta 24 of january. >> > >> > Stef >> > >> > On Jan 19, 2013, at 11:40 PM, Nicolas Cellier wrote: >> > >> >> >> >> I've now added support for BigEndian machine to LargeIntegersPlugin >> >> v2.0 (32 bits digits) >> >> On such machine, LargeIntegers (Positive or Negative) will be stored >> >> in big-endian (native) 32 bits words. >> >> If course, images will be saved with that peculiar byteOrder by a new VM. >> >> I used bit 7 (1<<6=64) of image headerFlags to flag the peculiarity. >> >> Eliot, let me know if you have bigger plan for that bit, and if so, >> >> please assign another one to my experiments. >> >> It will be easy to add reverse support to make an image readable by an >> >> old VM, if ever... >> >> >> >> Of course, I've got no such BigEndian machine. >> >> So it's up to a good soul to test it for me... (or a CI machine?) >> >> To produce a StackInterpreter VM, load VMMaker.oscog-nice.275 from the >> >> SmalltalkHub repository, then follow usual cog svn branch instructions >> >> to generate, compile, ... >> >> >> >> Before using the new VM on a BigEndian machine, a pre-requisite is to >> >> load/merge Kernel-nice.734 because it contains a definitions of >> >> #digitAt: #digitAt:put: and #digitLength compatible across different >> >> VM. >> >> >> >> There might be some nasty side effect if you try to copy >> >> LargeInt<->ByteArray with available primitives (I know some packages >> >> do it). When we are cheating (by letting LargeInt variable-byte) there >> >> must be a price to pay... Maybe I'll try to address this known >> >> limitation later. >> >> >> >> That's all for now, my VM hacking are mostly late-night, and I need a >> >> little rest. >> >> Let me know if you ever try the adventure of using dangerous early >> >> hour coding ;) >> >> >> >> Nicolas >> >> >> >> 2013/1/19 Nicolas Cellier <[hidden email]>: >> >>> I published code on SmalltalkHub (nice occasion to test it, and I did >> >>> not want to pollute source.squeak.org with experimental) in sync with >> >>> .oscog branch. >> >>> MCHttpRepository >> >>> location: 'http://smalltalkhub.com/mc/nice/NiceVMExperiments/main' >> >>> user: 'nice' >> >>> password: '' >> >>> >> >>> I also blogged about it >> >>> http://smallissimo.blogspot.fr/2013/01/update-on-squeak-largeinteger-32-bits.html >> >>> >> >>> I didn't take any care to make the code 64bits friendly. This will >> >>> require a review... >> >>> >> >>> Nicolas >> > |
Re: Accelerating LargeIntegersPlugin phase 2
|
|
On Sun, Jan 20, 2013 at 04:52:42PM +0000, Frank Shearar wrote: > > On 20 January 2013 15:37, David T. Lewis <[hidden email]> wrote: > > > > I'll mention also that, although much work remains to be done in merging > > oscog and trunk VM code bases, I think that overall we are doing very > > well with the primitives. The VM primitives are now almost all in class > > InterpreterPrimitives, and changes can easily by adopted in both branches. > > Likewise, the plugins such as LargeIntegersPlugin can easily be kept in > > sync in the two branches. > > > > That means that changes like these can be tested and adopted in either > > branch at the convenience of the person doing the work. I'm doing my > > best to pick up changes as they are added to Cog, and Eliot is doing > > likewise with changes that show up first in the interpreter VM. > > > > I don't happen to have a big endian machine, but hopefully someone else > > has one and can help out with the testing, using either an interpreter > > VM or Cog VM. > > At the risk of sounding rather ignorant, what kind of machine would > that be? IIRC the 68k machines were big endian but they've been wiped > out now haven't they? > Most certainly not, Edgar still has one. Wikipedia gives a good summary: http://en.wikipedia.org/wiki/Endianness Older Macs are big endian, and the Squeak VM was originally written on big endian machines. ARM processors can run in either mode. Most likely they run as little endian for Linux, and I'm not sure which mode is used for RISC OS. In any case, keeping the VM healthy for big and little endian machines is important to ensure portability of the VM. You never know when somebody is going to want to do a VM for System 360 ;-) Dave |
Re: Accelerating LargeIntegersPlugin phase 2
|
|
On 20 January 2013 17:39, David T. Lewis <[hidden email]> wrote: > > On Sun, Jan 20, 2013 at 04:52:42PM +0000, Frank Shearar wrote: >> >> On 20 January 2013 15:37, David T. Lewis <[hidden email]> wrote: >> > >> > I'll mention also that, although much work remains to be done in merging >> > oscog and trunk VM code bases, I think that overall we are doing very >> > well with the primitives. The VM primitives are now almost all in class >> > InterpreterPrimitives, and changes can easily by adopted in both branches. >> > Likewise, the plugins such as LargeIntegersPlugin can easily be kept in >> > sync in the two branches. >> > >> > That means that changes like these can be tested and adopted in either >> > branch at the convenience of the person doing the work. I'm doing my >> > best to pick up changes as they are added to Cog, and Eliot is doing >> > likewise with changes that show up first in the interpreter VM. >> > >> > I don't happen to have a big endian machine, but hopefully someone else >> > has one and can help out with the testing, using either an interpreter >> > VM or Cog VM. >> >> At the risk of sounding rather ignorant, what kind of machine would >> that be? IIRC the 68k machines were big endian but they've been wiped >> out now haven't they? >> > > Most certainly not, Edgar still has one. OK, that's pretty much what I meant :) > Wikipedia gives a good summary: http://en.wikipedia.org/wiki/Endianness > > Older Macs are big endian, and the Squeak VM was originally written on > big endian machines. ARM processors can run in either mode. Most likely > they run as little endian for Linux, and I'm not sure which mode is used > for RISC OS. Sadly my old macs went to the knacker's yard. > In any case, keeping the VM healthy for big and little endian machines is > important to ensure portability of the VM. You never know when somebody > is going to want to do a VM for System 360 ;-) Oh, I agree entirely! It keeps folks honest. frank > Dave > |
Re: Accelerating LargeIntegersPlugin phase 2
|
|
In reply to this post by David T. Lewis
A friend and I built this one out of a big pile of junked laptops, and then Woz signed it, because making things out of junk is cool. He especially liked the sandwich warmer where the optical drive is supposed to go. Long story, though, that.
:D PPC G3. Very Bigendian. Has notable sharpie ink on it. Smells funny, a bit like a locker room, because the G3 keyboards soaked up finger sweat in a weird way; with the G4 iBooks they switched to a different plastic for the keyboard that didn't yellow or stink.
Might be the most valuable laptop that smells this bad! On Sun, Jan 20, 2013 at 9:39 AM, David T. Lewis <[hidden email]> wrote:
<snip />
<snip /> Dave Casey Ransberger |
Photo on 3-29-13 at 3.15 AM.jpg (80K)
«
Return to Squeak VM
|
1 view|%1 views
| Free forum by Nabble | Edit this page |