The purpose of this change to the SystemReporter is to allow it to identify the image format and word size (64-bit or 32-bit) of the image file that is currently being run. An example SystemReporter window from a 64-bit image is attached.
A 64-bit version of the trunk image can be found here: http://box3.squeak.org/job/Squeak%2064-bit%20image/
A 64-bit image is normally created directly from the normal 32-bit image using a SystemTracer. This Smalltalk script illustrates how it is done: http://box3.squeak.org/job/Squeak%2064-bit%20image/ws/TraceTo64.st
To run a 64-bit image on Linux, go to http://squeakvm.org/unix/ and install both the "4.10.2.2614 Unix VM" and the "4.10.2.2614 Unix VM for 64-bit images". The /usr/local/bin/squeak script will then invoke the right VM to run your image, either 32- or 64-bit.
If you prefer to compile your VM from source, use the source tarball from http://squeakvm.org/unix/ and run the platforms/unix/cmake/configure script with the "--image64" option to build a VM for running 64-bit images. Unofficial and unsupported "bleeding edge" tarballs can also be found at http://box3.squeak.org/job/InterpreterVM/
Cog VMs are not currently able to run the 64-bit image, although they certainly will do so in the future. For now, a 64-bit image on a standard interpreter VM will be much slower than the "same" 32-bit image on Cog, but will have greater address space and an ability to reach a much larger total image size.
Dave
On Thu, Nov 08, 2012 at 04:36:15AM +0000, commits@source.squeak.org wrote:
David T. Lewis uploaded a new version of SystemReporter to project The Trunk: http://source.squeak.org/trunk/SystemReporter-dtl.20.mcz
==================== Summary ====================
Name: SystemReporter-dtl.20 Author: dtl Time: 7 November 2012, 11:35:58.387 pm UUID: fb07b2ef-d22a-4054-a266-1e94e274f3ef Ancestors: SystemReporter-cmm.19
Display image format and word size in #reportImage:
=============== Diff against SystemReporter-cmm.19 ===============
Item was changed: ----- Method: SystemReporter>>reportImage: (in category 'reporting') ----- reportImage: aStream self header: 'Image' on: aStream. aStream nextPutAll: Smalltalk image imageName; cr; nextPutAll: SystemVersion current version; cr; nextPutAll: Smalltalk image lastUpdateString; cr;
nextPutAll: Smalltalk image currentChangeSetString; cr.
- [ | imageFormat bitsPerWord |
- imageFormat := Smalltalk image imageFormatVersion.
- bitsPerWord := Smalltalk image wordSize * 8.
- aStream nextPutAll: 'Image format ';
nextPutAll: imageFormat asString;
nextPutAll: ' (';
nextPutAll: bitsPerWord asString;
nextPutAll: ' bit)'; cr]
on: Warning
do: ["primitive not present in VM"].
!nextPutAll: Smalltalk image currentChangeSetString; cr
Hi David -
This is great, and just in time! I wanted to play around with Squeak on my new z820 development workstation featuring some 256GB of Memory (heh, heh) and was wondering where I could find the right Image/VM pair. Thanks for the post!
Cheers, - Andreas
David T. Lewis wrote
The purpose of this change to the SystemReporter is to allow it to identify the image format and word size (64-bit or 32-bit) of the image file that is currently being run. An example SystemReporter window from a 64-bit image is attached.
A 64-bit version of the trunk image can be found here: http://box3.squeak.org/job/Squeak%2064-bit%20image/
A 64-bit image is normally created directly from the normal 32-bit image using a SystemTracer. This Smalltalk script illustrates how it is done: http://box3.squeak.org/job/Squeak%2064-bit%20image/ws/TraceTo64.st
To run a 64-bit image on Linux, go to http://squeakvm.org/unix/ and install both the "4.10.2.2614 Unix VM" and the "4.10.2.2614 Unix VM for 64-bit images". The /usr/local/bin/squeak script will then invoke the right VM to run your image, either 32- or 64-bit.
If you prefer to compile your VM from source, use the source tarball from http://squeakvm.org/unix/ and run the platforms/unix/cmake/configure script with the "--image64" option to build a VM for running 64-bit images. Unofficial and unsupported "bleeding edge" tarballs can also be found at http://box3.squeak.org/job/InterpreterVM/
Cog VMs are not currently able to run the 64-bit image, although they certainly will do so in the future. For now, a 64-bit image on a standard interpreter VM will be much slower than the "same" 32-bit image on Cog, but will have greater address space and an ability to reach a much larger total image size.
Dave
On Thu, Nov 08, 2012 at 04:36:15AM +0000,
commits@.squeak
wrote:
David T. Lewis uploaded a new version of SystemReporter to project The Trunk: http://source.squeak.org/trunk/SystemReporter-dtl.20.mcz
==================== Summary ====================
Name: SystemReporter-dtl.20 Author: dtl Time: 7 November 2012, 11:35:58.387 pm UUID: fb07b2ef-d22a-4054-a266-1e94e274f3ef Ancestors: SystemReporter-cmm.19
Display image format and word size in #reportImage:
=============== Diff against SystemReporter-cmm.19 ===============
Item was changed:
----- Method: SystemReporter>>reportImage: (in category 'reporting')
reportImage: aStream self header: 'Image' on: aStream. aStream nextPutAll: Smalltalk image imageName; cr; nextPutAll: SystemVersion current version; cr; nextPutAll: Smalltalk image lastUpdateString; cr;
nextPutAll: Smalltalk image currentChangeSetString; cr.
- [ | imageFormat bitsPerWord |
- imageFormat := Smalltalk image imageFormatVersion.
- bitsPerWord := Smalltalk image wordSize * 8.
- aStream nextPutAll: 'Image format ';
nextPutAll: imageFormat asString;
nextPutAll: ' (';
nextPutAll: bitsPerWord asString;
nextPutAll: ' bit)'; cr]
on: Warning
do: ["primitive not present in VM"].
!nextPutAll: Smalltalk image currentChangeSetString; cr
System Reporter.png (54K) <http://forum.world.st/attachment/4654568/0/System%20Reporter.png%3E;
-- View this message in context: http://forum.world.st/64-bit-images-was-The-Trunk-SystemReporter-dtl-20-mcz-... Sent from the Squeak - Dev mailing list archive at Nabble.com.
How long does a full GC take for, say, an 8 GB image with a gazillion of small objects?
- Bert -
On 2012-11-09, at 13:10, "Andreas.Raab" andreas.raab@gmx.de wrote:
Hi David -
This is great, and just in time! I wanted to play around with Squeak on my new z820 development workstation featuring some 256GB of Memory (heh, heh) and was wondering where I could find the right Image/VM pair. Thanks for the post!
Cheers,
- Andreas
David T. Lewis wrote
The purpose of this change to the SystemReporter is to allow it to identify the image format and word size (64-bit or 32-bit) of the image file that is currently being run. An example SystemReporter window from a 64-bit image is attached.
A 64-bit version of the trunk image can be found here: http://box3.squeak.org/job/Squeak%2064-bit%20image/
A 64-bit image is normally created directly from the normal 32-bit image using a SystemTracer. This Smalltalk script illustrates how it is done: http://box3.squeak.org/job/Squeak%2064-bit%20image/ws/TraceTo64.st
To run a 64-bit image on Linux, go to http://squeakvm.org/unix/ and install both the "4.10.2.2614 Unix VM" and the "4.10.2.2614 Unix VM for 64-bit images". The /usr/local/bin/squeak script will then invoke the right VM to run your image, either 32- or 64-bit.
If you prefer to compile your VM from source, use the source tarball from http://squeakvm.org/unix/ and run the platforms/unix/cmake/configure script with the "--image64" option to build a VM for running 64-bit images. Unofficial and unsupported "bleeding edge" tarballs can also be found at http://box3.squeak.org/job/InterpreterVM/
Cog VMs are not currently able to run the 64-bit image, although they certainly will do so in the future. For now, a 64-bit image on a standard interpreter VM will be much slower than the "same" 32-bit image on Cog, but will have greater address space and an ability to reach a much larger total image size.
Dave
On Fri, Nov 09, 2012 at 01:43:15PM +0100, Bert Freudenberg wrote:
How long does a full GC take for, say, an 8 GB image with a gazillion of small objects?
- Bert -
Sorry Bert, a gazillion requires the 128-bit object format ;)
My totally unscientific observation is that growing the object memory by filling it with large objects has no noticeable impact on GC performance. I don't have any measurements to offer, but I think we will find that GC performance will degrade as a (non linear) function of number of objects, and size of the objects will have no impact.
On 2012-11-09, at 13:10, "Andreas.Raab" andreas.raab@gmx.de wrote:
Hi David -
This is great, and just in time! I wanted to play around with Squeak on my new z820 development workstation featuring some 256GB of Memory (heh, heh) and was wondering where I could find the right Image/VM pair. Thanks for the post!
Cheers,
- Andreas
Cool! Please let us know how large an image you are able to create.
I'm not sure if those VMs have large file support enabled (very likely not), so you might need to recompile if you want to save your 255GB image file to disk.
Dave
David T. Lewis wrote
The purpose of this change to the SystemReporter is to allow it to identify the image format and word size (64-bit or 32-bit) of the image file that is currently being run. An example SystemReporter window from a 64-bit image is attached.
A 64-bit version of the trunk image can be found here: http://box3.squeak.org/job/Squeak%2064-bit%20image/
A 64-bit image is normally created directly from the normal 32-bit image using a SystemTracer. This Smalltalk script illustrates how it is done: http://box3.squeak.org/job/Squeak%2064-bit%20image/ws/TraceTo64.st
To run a 64-bit image on Linux, go to http://squeakvm.org/unix/ and install both the "4.10.2.2614 Unix VM" and the "4.10.2.2614 Unix VM for 64-bit images". The /usr/local/bin/squeak script will then invoke the right VM to run your image, either 32- or 64-bit.
If you prefer to compile your VM from source, use the source tarball from http://squeakvm.org/unix/ and run the platforms/unix/cmake/configure script with the "--image64" option to build a VM for running 64-bit images. Unofficial and unsupported "bleeding edge" tarballs can also be found at http://box3.squeak.org/job/InterpreterVM/
Cog VMs are not currently able to run the 64-bit image, although they certainly will do so in the future. For now, a 64-bit image on a standard interpreter VM will be much slower than the "same" 32-bit image on Cog, but will have greater address space and an ability to reach a much larger total image size.
Dave
On 09-11-2012, at 7:22 AM, "David T. Lewis" lewis@mail.msen.com wrote:
On Fri, Nov 09, 2012 at 01:43:15PM +0100, Bert Freudenberg wrote:
How long does a full GC take for, say, an 8 GB image with a gazillion of small objects?
- Bert -
Sorry Bert, a gazillion requires the 128-bit object format ;)
My totally unscientific observation is that growing the object memory by filling it with large objects has no noticeable impact on GC performance. I don't have any measurements to offer, but I think we will find that GC performance will degrade as a (non linear) function of number of objects, and size of the objects will have no impact.
Assuming not too much has been changed in the GC stuff, large objects tend to end up in the old-space region and don't get looked at very often. To torture the incremental gc code try something like creating a tree of associations, each with a key of another association and a value of another one. Repeat for perhaps 30 million. Go make dinner…
Oh, wait, Bert did specify a full GC; well that will of course scan all those big objects in old space too, so add 'grow your vegetables first'. Unless they are predominantly non-pointer objects, which get skipped over.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Looks for the "Any" key.
Hello Andreas,
That's great to hear about your plans on Squeak experiments with so strong hardware! And could you please shed light on the current OpenQwaq development status? What are the priorities for current and future research work?
Regards, Nikolay
On Fri, Nov 9, 2012 at 4:10 PM, Andreas.Raab andreas.raab@gmx.de wrote:
Hi David -
This is great, and just in time! I wanted to play around with Squeak on my new z820 development workstation featuring some 256GB of Memory (heh, heh) and was wondering where I could find the right Image/VM pair. Thanks for the post!
Cheers,
- Andreas
David T. Lewis wrote
The purpose of this change to the SystemReporter is to allow it to identify the image format and word size (64-bit or 32-bit) of the image file that is currently being run. An example SystemReporter window from a 64-bit image is attached.
A 64-bit version of the trunk image can be found here: http://box3.squeak.org/job/Squeak%2064-bit%20image/
A 64-bit image is normally created directly from the normal 32-bit image using a SystemTracer. This Smalltalk script illustrates how it is done: http://box3.squeak.org/job/Squeak%2064-bit%20image/ws/TraceTo64.st
To run a 64-bit image on Linux, go to http://squeakvm.org/unix/ and install both the "4.10.2.2614 Unix VM" and the "4.10.2.2614 Unix VM for 64-bit images". The /usr/local/bin/squeak script will then invoke the right VM to run your image, either 32- or 64-bit.
If you prefer to compile your VM from source, use the source tarball from http://squeakvm.org/unix/ and run the
platforms/unix/cmake/configure
script with the "--image64" option to build a VM for running 64-bit images. Unofficial and unsupported "bleeding edge" tarballs can also be found at http://box3.squeak.org/job/InterpreterVM/
Cog VMs are not currently able to run the 64-bit image, although they certainly will do so in the future. For now, a 64-bit image on a standard interpreter VM will be much slower than the "same" 32-bit image on Cog, but will have greater address space and an ability to reach a much larger total image size.
Dave
On Thu, Nov 08, 2012 at 04:36:15AM +0000,
commits@.squeak
wrote:
David T. Lewis uploaded a new version of SystemReporter to project The Trunk: http://source.squeak.org/trunk/SystemReporter-dtl.20.mcz
==================== Summary ====================
Name: SystemReporter-dtl.20 Author: dtl Time: 7 November 2012, 11:35:58.387 pm UUID: fb07b2ef-d22a-4054-a266-1e94e274f3ef Ancestors: SystemReporter-cmm.19
Display image format and word size in #reportImage:
=============== Diff against SystemReporter-cmm.19 ===============
Item was changed:
----- Method: SystemReporter>>reportImage: (in category 'reporting')
reportImage: aStream self header: 'Image' on: aStream. aStream nextPutAll: Smalltalk image imageName; cr; nextPutAll: SystemVersion current version; cr; nextPutAll: Smalltalk image lastUpdateString; cr;
nextPutAll: Smalltalk image currentChangeSetString; cr.
- [ | imageFormat bitsPerWord |
- imageFormat := Smalltalk image imageFormatVersion.
- bitsPerWord := Smalltalk image wordSize * 8.
- aStream nextPutAll: 'Image format ';
nextPutAll: imageFormat asString;
nextPutAll: ' (';
nextPutAll: bitsPerWord asString;
nextPutAll: ' bit)'; cr]
on: Warning
do: ["primitive not present in VM"].
!nextPutAll: Smalltalk image currentChangeSetString; cr
System Reporter.png (54K) <http://forum.world.st/attachment/4654568/0/System%20Reporter.png%3E;
-- View this message in context: http://forum.world.st/64-bit-images-was-The-Trunk-SystemReporter-dtl-20-mcz-... Sent from the Squeak - Dev mailing list archive at Nabble.com.
squeak-dev@lists.squeakfoundation.org