[Pharo-project] Design change possible with fast SSD's possible?
Hi! I am just reviewing some timing adjustments in Linux, which came neccessary due to the tremendous speed improvements of SSD Raid, > 1 mio IOPS, compared to fastest Barracudas disks with > 200 IOPS max. IS there still a "Image" neccessary in Smalltalk then? Or has this former "design approach" nowerdays rather significant disadvantages? (32 Bit, hanging IO during sync, GC....) Tnx, Guido Stepken Am 13.01.2012 20:43 schrieb "Gastón Dall' Oglio" < gaston.dalloglio@gmail.com>:
Congratulation for the team!!!
A little comment, in the page of OpenDBX the name and link of DBXTalk are bad (SqueakDBX): http://www.linuxnetworks.de/doc/index.php/OpenDBX
On 14 January 2012 12:13, Guido Stepken <gstepken@googlemail.com> wrote:
IS there still a "Image" neccessary in Smalltalk then? Or has this former "design approach" nowerdays rather significant disadvantages? (32 Bit, hanging IO during sync, GC....)
As I see it, image is not something that has to reside in physical RAM, but it is necessary in Smalltalk. -- Milan Mimica http://sparklet.sf.net
Why can't i take a SSD drive as Image? 2 GByte limit automatically falls? Am 14.01.2012 13:10 schrieb "Milan Mimica" <milan.mimica@gmail.com>:
On 14 January 2012 12:13, Guido Stepken <gstepken@googlemail.com> wrote:
IS there still a "Image" neccessary in Smalltalk then? Or has this former "design approach" nowerdays rather significant disadvantages? (32 Bit, hanging IO during sync, GC....)
As I see it, image is not something that has to reside in physical RAM, but it is necessary in Smalltalk.
-- Milan Mimica http://sparklet.sf.net
I'm no expert but I think it would make quite a difference to the VM in terms of data access. I guess that the changes to the VM would be pretty radical. Max On 14.01.2012, at 14:08, Guido Stepken wrote:
Why can't i take a SSD drive as Image? 2 GByte limit automatically falls?
Am 14.01.2012 13:10 schrieb "Milan Mimica" <milan.mimica@gmail.com>: On 14 January 2012 12:13, Guido Stepken <gstepken@googlemail.com> wrote: IS there still a "Image" neccessary in Smalltalk then? Or has this former "design approach" nowerdays rather significant disadvantages? (32 Bit, hanging IO during sync, GC....)
As I see it, image is not something that has to reside in physical RAM, but it is necessary in Smalltalk.
-- Milan Mimica http://sparklet.sf.net
Slightly of topic: I won't be surprised if one actually come out with a solution similar to L1, L2 etc caches in CPU vs.outside RAM. CPU cache is namelly several times faster tham RAM. While mechanical disks were several 1000 times slower than RAM. Until now when SSDs are aproaching the speed of RAM. Conclusion? Why RAM won't be just a L3 cache in a whole hiearchy of caching from SSD up to CPU? Automatic, supported by OS or even hardware, as CPU caches are? Then image wont be needed to be read to RAM and snapshoted back to disk, it can be run directly from disk. Janko S, Max Leske piše:
I'm no expert but I think it would make quite a difference to the VM in terms of data access. I guess that the changes to the VM would be pretty radical.
Max
On 14.01.2012, at 14:08, Guido Stepken wrote:
Why can't i take a SSD drive as Image? 2 GByte limit automatically falls?
Am 14.01.2012 13:10 schrieb "Milan Mimica" <milan.mimica@gmail.com <mailto:milan.mimica@gmail.com>>:
On 14 January 2012 12:13, Guido Stepken <gstepken@googlemail.com <mailto:gstepken@googlemail.com>> wrote:
IS there still a "Image" neccessary in Smalltalk then? Or has this former "design approach" nowerdays rather significant disadvantages? (32 Bit, hanging IO during sync, GC....)
As I see it, image is not something that has to reside in physical RAM, but it is necessary in Smalltalk.
-- Milan Mimica http://sparklet.sf.net <http://sparklet.sf.net/>
-- Janko Mivšek Svetovalec za informatiko Eranova d.o.o. Ljubljana, Slovenija www.eranova.si tel: 01 514 22 55 faks: 01 514 22 56 gsm: 031 674 565
Hi, 2012/1/14 Janko Mivšek <janko.mivsek@eranova.si>:
Conclusion? Why RAM won't be just a L3 cache in a whole hiearchy of caching from SSD up to CPU? Automatic, supported by OS or even hardware, as CPU caches are? Then image wont be needed to be read to RAM and snapshoted back to disk, it can be run directly from disk.
SSDs are Flash memory. The number of write cycles is limited before the memory starts to fail. Smalltalk frequently performs GC, which involves moving objects, i.e., writing. Writing is also much slower than reading, and AFAIK possible only block-wise (with a block being significantly larger than your average object). Flash file systems apply optimisations to distribute writing evenly, avoiding excessive writing in some places and consequent earlier failure. Best, Michael
Read about "wear leveling"? So, no problem with write cycles. For example yffs2 filesystem gives you a tremendous gain in lifetime of your USB flash storage. regards, Guido Stepken Am 14.01.2012 15:56 schrieb "Michael Haupt" <mhaupt@gmail.com>:
Hi,
2012/1/14 Janko Mivšek <janko.mivsek@eranova.si>:
Conclusion? Why RAM won't be just a L3 cache in a whole hiearchy of caching from SSD up to CPU? Automatic, supported by OS or even hardware, as CPU caches are? Then image wont be needed to be read to RAM and snapshoted back to disk, it can be run directly from disk.
SSDs are Flash memory. The number of write cycles is limited before the memory starts to fail. Smalltalk frequently performs GC, which involves moving objects, i.e., writing. Writing is also much slower than reading, and AFAIK possible only block-wise (with a block being significantly larger than your average object). Flash file systems apply optimisations to distribute writing evenly, avoiding excessive writing in some places and consequent earlier failure.
Best,
Michael
... thanks for the pointer. How about writing speed and modalities? Am 14.01.2012 um 19:34 schrieb Guido Stepken <gstepken@googlemail.com>:
Read about "wear leveling"? So, no problem with write cycles. For example yffs2 filesystem gives you a tremendous gain in lifetime of your USB flash storage.
regards, Guido Stepken
Am 14.01.2012 15:56 schrieb "Michael Haupt" <mhaupt@gmail.com>: Hi,
2012/1/14 Janko Mivšek <janko.mivsek@eranova.si>:
Conclusion? Why RAM won't be just a L3 cache in a whole hiearchy of caching from SSD up to CPU? Automatic, supported by OS or even hardware, as CPU caches are? Then image wont be needed to be read to RAM and snapshoted back to disk, it can be run directly from disk.
SSDs are Flash memory. The number of write cycles is limited before the memory starts to fail. Smalltalk frequently performs GC, which involves moving objects, i.e., writing. Writing is also much slower than reading, and AFAIK possible only block-wise (with a block being significantly larger than your average object). Flash file systems apply optimisations to distribute writing evenly, avoiding excessive writing in some places and consequent earlier failure.
Best,
Michael
... BTW that's what I meant with optimisations. Am 14.01.2012 um 19:34 schrieb Guido Stepken <gstepken@googlemail.com>:
Read about "wear leveling"? So, no problem with write cycles. For example yffs2 filesystem gives you a tremendous gain in lifetime of your USB flash storage.
regards, Guido Stepken
Am 14.01.2012 15:56 schrieb "Michael Haupt" <mhaupt@gmail.com>: Hi,
2012/1/14 Janko Mivšek <janko.mivsek@eranova.si>:
Conclusion? Why RAM won't be just a L3 cache in a whole hiearchy of caching from SSD up to CPU? Automatic, supported by OS or even hardware, as CPU caches are? Then image wont be needed to be read to RAM and snapshoted back to disk, it can be run directly from disk.
SSDs are Flash memory. The number of write cycles is limited before the memory starts to fail. Smalltalk frequently performs GC, which involves moving objects, i.e., writing. Writing is also much slower than reading, and AFAIK possible only block-wise (with a block being significantly larger than your average object). Flash file systems apply optimisations to distribute writing evenly, avoiding excessive writing in some places and consequent earlier failure.
Best,
Michael
.. also SSD won't necessary use Flash technology in the future, there are already alternatives close to production level, which solve exactly that write problem. In any case, in few years we will have such a hierarchical persistent memory from slow SSD up to fastest CPU caches available. S, Michael Haupt piše:
... BTW that's what I meant with optimisations.
Am 14.01.2012 um 19:34 schrieb Guido Stepken <gstepken@googlemail.com <mailto:gstepken@googlemail.com>>:
Read about "wear leveling"? So, no problem with write cycles. For example yffs2 filesystem gives you a tremendous gain in lifetime of your USB flash storage.
regards, Guido Stepken
Am 14.01.2012 15:56 schrieb "Michael Haupt" <mhaupt@gmail.com <mailto:mhaupt@gmail.com>>:
Hi,
2012/1/14 Janko Mivšek <janko.mivsek@eranova.si <mailto:janko.mivsek@eranova.si>>: > Conclusion? Why RAM won't be just a L3 cache in a whole hiearchy of > caching from SSD up to CPU? Automatic, supported by OS or even hardware, > as CPU caches are? Then image wont be needed to be read to RAM and > snapshoted back to disk, it can be run directly from disk.
SSDs are Flash memory. The number of write cycles is limited before the memory starts to fail. Smalltalk frequently performs GC, which involves moving objects, i.e., writing. Writing is also much slower than reading, and AFAIK possible only block-wise (with a block being significantly larger than your average object). Flash file systems apply optimisations to distribute writing evenly, avoiding excessive writing in some places and consequent earlier failure.
Best,
Michael
-- Janko Mivšek Svetovalec za informatiko Eranova d.o.o. Ljubljana, Slovenija www.eranova.si tel: 01 514 22 55 faks: 01 514 22 56 gsm: 031 674 565
On 14 Jan 2012, at 19:34, Guido Stepken wrote:
Read about "wear leveling"? So, no problem with write cycles. For example yffs2 filesystem gives you a tremendous gain in lifetime of your USB flash storage.
Just tell your OS to use your SSD as swap drive, and you got what you want. Without any VM changes. Best regards Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525
Hi Stefan, Am 14.01.2012 um 19:56 schrieb Stefan Marr <smalltalk@stefan-marr.de>:
Just tell your OS to use your SSD as swap drive, and you got what you want. Without any VM changes.
that's a nice way to see a Smalltalk image with its contents frequently moving about due to GC ... ;-) Best, Michael
The 2Gb limit has nothing to do with where the image is stored. The limit is in the image itself. The image on the SSD drive cannot be your working image because Pharo works on a *copy* of the image, not on the image itself. That is by design - otherwise you wouldn't have the possibility to rollback to a last saved image. On 14 January 2012 14:08, Guido Stepken <gstepken@googlemail.com> wrote:
Why can't i take a SSD drive as Image? 2 GByte limit automatically falls? Am 14.01.2012 13:10 schrieb "Milan Mimica" <milan.mimica@gmail.com>:
On 14 January 2012 12:13, Guido Stepken <gstepken@googlemail.com> wrote:
IS there still a "Image" neccessary in Smalltalk then? Or has this former "design approach" nowerdays rather significant disadvantages? (32 Bit, hanging IO during sync, GC....)
As I see it, image is not something that has to reside in physical RAM, but it is necessary in Smalltalk.
-- Milan Mimica http://sparklet.sf.net
-- Milan Mimica http://sparklet.sf.net
On 14 January 2012 14:41, Milan Mimica <milan.mimica@gmail.com> wrote:
The 2Gb limit has nothing to do with where the image is stored. The limit is in the image itself. The image on the SSD drive cannot be your working image because Pharo works on a *copy* of the image, not on the image itself. That is by design - otherwise you wouldn't have the possibility to rollback to a last saved image.
VM just loads an image from file into memory, and then just continues running it. And once it started you can delete file on disk without any consequences. In other words, it is not important where you get the object memory snapshot from: be it file on hard drive or downloaded from network node or residing in ROM. It used only at booting stage of VM, and then it operates with it in memory, without accessing external storage anymore. But this is squeak VM. A Gemstone one constantly using external storage for loading/storing modified pages of object memory, so it not necessary needs to hold a full object memory in RAM, only portion of it. And yes, it allows Giga-Terrabytes big "images" i.e. object memory size.
On 14 January 2012 14:08, Guido Stepken <gstepken@googlemail.com> wrote:
Why can't i take a SSD drive as Image? 2 GByte limit automatically falls?
Am 14.01.2012 13:10 schrieb "Milan Mimica" <milan.mimica@gmail.com>:
On 14 January 2012 12:13, Guido Stepken <gstepken@googlemail.com> wrote:
IS there still a "Image" neccessary in Smalltalk then? Or has this former "design approach" nowerdays rather significant disadvantages? (32 Bit, hanging IO during sync, GC....)
As I see it, image is not something that has to reside in physical RAM, but it is necessary in Smalltalk.
-- Milan Mimica http://sparklet.sf.net
-- Milan Mimica http://sparklet.sf.net
-- Best regards, Igor Stasenko.
Disadvantages, in addition to the advantages of a live environment? The later are undeniable, and the size restrictions are probably avoidable (it can be amazing what "thinking outside the box" can allow). Perhaps I misunderstand you. If want to provide the current live environment experience w/o an image file, that might be a great idea - I am certainly willing to consider it. If you want to reduce us to stateless source files (just) so we can be "like other languages," then I start to disagree. Bill ________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Guido Stepken [gstepken@googlemail.com] Sent: Saturday, January 14, 2012 6:13 AM To: Pharo-project@lists.gforge.inria.fr Subject: [Pharo-project] Design change possible with fast SSD's possible? Hi! I am just reviewing some timing adjustments in Linux, which came neccessary due to the tremendous speed improvements of SSD Raid, > 1 mio IOPS, compared to fastest Barracudas disks with > 200 IOPS max. IS there still a "Image" neccessary in Smalltalk then? Or has this former "design approach" nowerdays rather significant disadvantages? (32 Bit, hanging IO during sync, GC....) Tnx, Guido Stepken Am 13.01.2012 20:43 schrieb "Gastón Dall' Oglio" <gaston.dalloglio@gmail.com<mailto:gaston.dalloglio@gmail.com>>: Congratulation for the team!!! A little comment, in the page of OpenDBX the name and link of DBXTalk are bad (SqueakDBX): http://www.linuxnetworks.de/doc/index.php/OpenDBX
participants (8)
-
Guido Stepken -
Igor Stasenko -
Janko Mivšek -
Max Leske -
Michael Haupt -
Milan Mimica -
Schwab,Wilhelm K -
Stefan Marr