January 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Design change possible with fast SSD's possible?

by Michael Haupt

Hi, 2012/1/14 Janko MivÅ¡ek <janko.mivsek(a)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

Jan. 14, 2012

Re: [Pharo-project] Design change possible with fast SSD's possible?

by Janko MivÅ¡ek

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(a)gmail.com >> <mailto:milan.mimica@gmail.com>>: >> >> On 14 January 2012 12:13, Guido Stepken <gstepken(a)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

Jan. 14, 2012

Re: [Pharo-project] Design change possible with fast SSD's possible?

by Igor Stasenko

On 14 January 2012 14:41, Milan Mimica <milan.mimica(a)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(a)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(a)gmail.com>: >> >>> On 14 January 2012 12:13, Guido Stepken <gstepken(a)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.

Jan. 14, 2012

Re: [Pharo-project] [Interesting] Drive to remove unused code in LibreOffice

by Schwab,Wilhelm K

Is this an opportunity for Moose to shine? ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Sven Van Caekenberghe [sven(a)beta9.be] Sent: Saturday, January 14, 2012 6:55 AM To: Pharo-project(a)lists.gforge.inria.fr Development Subject: [Pharo-project] [Interesting] Drive to remove unused code in LibreOffice http://www.i-programmer.info/news/136-open-source/3607-drive-to-remove-unus… probably a problem in every large code base

Jan. 14, 2012

Re: [Pharo-project] Design change possible with fast SSD's possible?

by Schwab,Wilhelm K

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(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Guido Stepken [gstepken(a)googlemail.com] Sent: Saturday, January 14, 2012 6:13 AM To: Pharo-project(a)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(a)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

Jan. 14, 2012

Re: [Pharo-project] Design change possible with fast SSD's possible?

by Milan Mimica

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(a)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(a)gmail.com>: > > On 14 January 2012 12:13, Guido Stepken <gstepken(a)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

Jan. 14, 2012

Re: [Pharo-project] Design change possible with fast SSD's possible?

by Max Leske

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(a)gmail.com>: > On 14 January 2012 12:13, Guido Stepken <gstepken(a)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

Jan. 14, 2012

Re: [Pharo-project] Design change possible with fast SSD's possible?

by Guido Stepken

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(a)gmail.com>: > On 14 January 2012 12:13, Guido Stepken <gstepken(a)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 >

Jan. 14, 2012

[Pharo-project] a fix to KomServer

by Milan Mimica

oops, looks like I have committed something... I have committed a patch to http://www.squeaksource.com/KomHttpServer I wanted to have it checked by someone first, didn't really think it would let me commit just like that. Sorry for the inconvenience. Anyway, now that it's there someone has to look at it. :) It's not much. The problem was KomServer threw MNO when a request was made with an absolute URL in the HTTP request, which is valid as I read it [1][2]. [1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.2.1 [2] http://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html#sec5.2 -- Milan Mimica http://sparklet.sf.net

Jan. 14, 2012

Re: [Pharo-project] Design change possible with fast SSD's possible?

by Milan Mimica

On 14 January 2012 12:13, Guido Stepken <gstepken(a)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

Jan. 14, 2012