September 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] google issue 3236

by StÃ©phane Ducasse

Thanks! We will. Stef On Sep 27, 2011, at 10:30 AM, Norbert Hartl wrote: > Ok, I got it working by splitting the change into 3 packages that need to be integrated separately. All chronology tests pass. > > Would be nice if you consider integrating it. > > Norbert > > Am 26.09.2011 um 20:30 schrieb StÃ©phane Ducasse: > >> tx for the information >> >> On Sep 26, 2011, at 6:50 PM, Norbert Hartl wrote: >> >>> >>> Am 26.09.2011 um 18:19 schrieb StÃ©phane Ducasse: >>> >>>> sure it will >>> >>> Now I see why it wasn't integrated. The fix is not that easy as it is in the bug entry. >>> >>>> Now did you check the motivation? >>> >>> Of the issue? Of course, to get time information that contains milliseconds and not only seconds. >>> >>>> Was it good? >>> >>> I think yes. The milliSecondClock is nothing reliable. You need to fiddle with it to get a real millisecond value. >>> >>>> Worth to get it in? >>> >>> Yes, I need to be able to measure milliseconds. I could use milliSecondClock but I think it is good for pharo to integrate it into DateAndTime properly. >>> >>> Norbert >>> >>>> On Sep 26, 2011, at 5:24 PM, Norbert Hartl wrote: >>>> >>>>> >>>>> Am 26.09.2011 um 16:40 schrieb Marcus Denker: >>>>> >>>>>> >>>>>> On Sep 26, 2011, at 4:36 PM, Norbert Hartl wrote: >>>>>> >>>>>>> Does anybody know what happened to >>>>>>> >>>>>>> http://code.google.com/p/pharo/issues/detail?id=3236 >>>>>>> >>>>>>> In pharo-1.3 and pharo-1.4 they aren't in. Well, that matches the status of FixedWaitingToBePharoed. Last change by Marcus is from April 7th. >>>>>>> >>>>>> >>>>>> Every issue not closed has yet to be done. >>>>>> >>>>>> So the anwer is: Nothing happend. >>>>>> >>>>> Ok, >>>>> >>>>> there was only a diff so I guess it was more manual work to have it integrated. I'm redoing the stuff on a fresh 1.4 image so it can be easily integrated. I hope this will help getting it in. >>>>> >>>>> Norbert >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> > >

Sept. 27, 2011

[Pharo-project] [update 1.4] #14168

by Marcus Denker

14168 ----- Issue 4809: PluggableListMorph improvment http://code.google.com/p/pharo/issues/detail?id=4809 -- Marcus Denker -- http://marcusdenker.de

Sept. 27, 2011

Re: [Pharo-project] google issue 3236

by Norbert Hartl

Ok, I got it working by splitting the change into 3 packages that need to be integrated separately. All chronology tests pass. Would be nice if you consider integrating it. Norbert Am 26.09.2011 um 20:30 schrieb StÃ©phane Ducasse: > tx for the information > > On Sep 26, 2011, at 6:50 PM, Norbert Hartl wrote: > >> >> Am 26.09.2011 um 18:19 schrieb StÃ©phane Ducasse: >> >>> sure it will >> >> Now I see why it wasn't integrated. The fix is not that easy as it is in the bug entry. >> >>> Now did you check the motivation? >> >> Of the issue? Of course, to get time information that contains milliseconds and not only seconds. >> >>> Was it good? >> >> I think yes. The milliSecondClock is nothing reliable. You need to fiddle with it to get a real millisecond value. >> >>> Worth to get it in? >> >> Yes, I need to be able to measure milliseconds. I could use milliSecondClock but I think it is good for pharo to integrate it into DateAndTime properly. >> >> Norbert >> >>> On Sep 26, 2011, at 5:24 PM, Norbert Hartl wrote: >>> >>>> >>>> Am 26.09.2011 um 16:40 schrieb Marcus Denker: >>>> >>>>> >>>>> On Sep 26, 2011, at 4:36 PM, Norbert Hartl wrote: >>>>> >>>>>> Does anybody know what happened to >>>>>> >>>>>> http://code.google.com/p/pharo/issues/detail?id=3236 >>>>>> >>>>>> In pharo-1.3 and pharo-1.4 they aren't in. Well, that matches the status of FixedWaitingToBePharoed. Last change by Marcus is from April 7th. >>>>>> >>>>> >>>>> Every issue not closed has yet to be done. >>>>> >>>>> So the anwer is: Nothing happend. >>>>> >>>> Ok, >>>> >>>> there was only a diff so I guess it was more manual work to have it integrated. I'm redoing the stuff on a fresh 1.4 image so it can be easily integrated. I hope this will help getting it in. >>>> >>>> Norbert >>>> >>>> >>>> >>> >>> >> >> > >

Sept. 27, 2011

Re: [Pharo-project] PetitSmalltalk: now with a self-contained grammar for number literals

by Frank Shearar

On 25 September 2011 15:21, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > 2011/9/25 Frank Shearar <frank.shearar(a)gmail.com>: >> Nicolas, you'd mentioned a log_2 n implementation for number parsing. >> I think by that you mean the division of digits into two "packets" >> that are processed and then added? >> >> I tried a straight-forward fold (using the * 10 that you said you didn't like!) >> >> Time millisecondsToRun: [10000 timesRepeat: >> ['123456789012345678901234567890' inject: 0 into: [:acc :each | 10 * >> acc + each digitValue]]] => 818 >> >> and what I think you meant: >> >> | f | >> f := 1. "Just to shut the compiler up about the self-reference." >> f := [:someDigits | | len | >> Â Â Â Â len := someDigits size. >> Â Â Â Â (len = 1) >> Â Â Â Â Â Â Â Â ifTrue: [someDigits first digitValue] >> Â Â Â Â Â Â Â Â ifFalse: [ | leftHalf rightHalf | >> Â Â Â Â Â Â Â Â Â Â Â Â leftHalf := someDigits first: len // 2. >> Â Â Â Â Â Â Â Â Â Â Â Â rightHalf := someDigits allButFirst: len // 2. >> Â Â Â Â Â Â Â Â Â Â Â Â ((f value: (leftHalf)) * (10 raisedTo: rightHalf size)) + (f value: >> rightHalf)]]. >> Time millisecondsToRun: [10000 timesRepeat: [f value: >> '123456789012345678901234567890']] => 1508 >> >> I went with the straight-forward fold because it was simpler and my >> (quite possibly wrong/inefficient) attempt at a log_2 n version was a >> lot less readable. >> >> I'd greatly appreciate being gently corrected! >> >> frank >> > > Hmm, let's see. > > Suppose that SmallIntegers are on 3 digits, and Large begins at 4. > And let's compose a 32 digits number 12345678901234567890123456789012 > > If I do the naive loop the first 3 loops (6 ops) give small ints. > Then the next 29 loops (58 ops) are performed with large ints. > > Now, if I perform these ops: > > ((1234 * (10**4) + 5678) * (10**8) + (9012 * (10**4) + 3456)) * > (10**16) + ((7890 * (10**16) + 1234) * (10**8) + (5678 * (10**4) + > 9012)) > > This time, I have 24 loops with small int (48 ops) and 8 loops (16 > ops) with large ints for evaluating the 4 digits ints. > Plus 14 operations to assemble these large ints into the final result. > Plus a number of operations required to evaluate the powers of 10: > without cache, this is > > 10**4 = 10 squared squared (1 small op + 1 large) * 4 times. > 10**8 = 10 squared squared squared (1 small op + 2 large) * 2 times. > 10**16 = 10 squared squared squared (1 small op + 3 large) * 1 time. > > The total is 55 ops on small ints + 41 ops on large ints. > So the second algorithm costs more operations on total, but cheaper ones. > Suppose every operation on SmallInteger costs 1 and LargeInteger costs 10, > we have a cost of 586 for the first, 465 for the second. > > Also, the cost of Large int operations is not constant. > It is proportional to max(length1,length2) for + and to length1*length2 for *. > So, we'll consider length(10**n)=n. > In first case, length2=1 and length1 is varying linearly between 4 and > 32, thus a mean of 18*2 digit ops per loop * 29 loops. > > In the second case, the cost in digit ops is: > 1) (3*1+4) per loop * 8 loops for forming the 4 digits elementary large ints > 2) (4*4+8) per loop * 4 loops for forming the 8 digits large ints > 3) (8*8+16) per loop * 2 loops for forming the 16 digits large ints > 4) (16*16+32) for the last iteration > > Plus the costs of evaluating powers of 10: > 1) (100 squared) is evaluated 7 times * (2*2) digit ops > 2) (10000 squared) is evaluated 3 times * (4*4) digit ops > 3) (100000000 squared) is evaluated 1 times * (8*8) digit ops > > grand total is 18*2*29 = 1044 digit ops for the naive algorithm > For the divide and conquer form, that is ((3*1+4)*8) + ((4*4+8)*4) + > ((8*8+16)*2) + (16*16+32) + (2*2*7) + (4*4*3) + (8*8) Â = 740 > > In your 30 decimal digits example, large integers are formed of 10 > decimal digits (SmallInteger maxVal + 1) printString size, so we would > have to translate above count... > But it's boring, we can lazily bench it: > > | stream | > stream := '123456789012345678901234567890' readStream. > { > [stream reset; nextFloat] bench. > [stream reset. Number readFrom: stream] bench. > } > Â #('15,600 per second.' '23,500 per second.') "Old 4.2 VM" > Â #('56,100 per second.' '97,700 per second.') "recent COG VM" > > Stream>>nextFloat is a naive loop with almost every operation inlined. > Number>>readFrom: traverses a bunch of sends before the real > operations take place. To be fair though, stream>>nextFloat is strictly less expressive than either Number class>>readFrom: or the extension to PetitSmalltalk under review: '16r1.0e10' readStream nextFloat 16.0 Number readFrom: '16r1.0e10' 1.054931640625 PPSmalltalkNumberParser new parse: '16r1.0e10' 1.054931640625. (And Number class >> #readFrom: is precisely the thing I'm trying to avoid: the Squeak and Pharo implementations have very different ideas of what a number is.) PPSmalltalkNumberParser2 uses the divide-and-conquer algorithm from above: | stream pp pp2 | stream := '123456789012345678901234567890' readStream. pp := PPSmalltalkNumberParser new. pp2 := PPSmalltalkNumberParser2 new. { [stream reset; nextFloat] bench. [stream reset. Number readFrom: stream] bench. [stream reset. pp parse: stream.] bench. [stream reset. pp2 parse: stream.] bench } #('10,500 per second.' '13,400 per second.' '1,560 per second.' '1,390 per second.') so right now my parser's rubbish: it's 10x slower. Most of that cost will probably come from the nature of the separation of grammar from evaluation: #nextFloat parses and creates the float in one go. frank > The overhead equlibrates around 12 decimal digits in non COG VM ! > That's why it was already faster for scanning a 15 digits Float (non > counting the fact that nextFloat fails to answer the nearest Float). > Now, in COG, it equilibrates around 20 digits. > > If we want to draw the cost versus log of number of digits: > > | gen counts serie cost1 cost2 | > gen := Generator on: [:g | [g yield: '1234567890' atRandom] repeat]. > counts := (2 to: 13) collect: [:e | 2 raisedTo: e]. > serie := counts collect: [:count | > Â Â Â Â String withAll: (gen next: count)]. > cost1 := serie collect: [:e | > Â Â Â Â [1000 timesRepeat: [e readStream nextFloat]] timeToRun]. > cost2 := serie collect: [:e | > Â Â Â Â [1000 timesRepeat: [(Number readFrom: e readStream) asFloat]] timeToRun]. > {counts. cost1. cost2.} > Â #("NON COG VM" > Â #(4 8 16 32 64 128 256 512 1024 2048 4096 8192) > Â #(2 2 25 65 146 304 647 1412 3288 8393 24021 77189) > Â #(6 6 21 51 94 177 361 742 1550 3872 8471 22647)) > > Â #("COG VM" > #(4 8 16 32 64 128 256 512 1024 2048 4096 8192) > Â #(0 2 3 20 56 139 334 838 2323 7010 23614 85925) > #(2 0 4 13 24 53 116 264 626 1646 4552 14191)) > > It's not a log_2 cost at the end, but it's already some gain. > It's possible that above costs are dominated by garbage collection, > but I don't know how to measure that accurately... > > Nicolas > >> On 14 September 2011 20:26, Frank Shearar <frank.shearar(a)gmail.com> wrote: >>> On 3 September 2011 19:35, Nicolas Cellier >>> <nicolas.cellier.aka.nice(a)gmail.com> wrote: >>>> 2011/9/3 Frank Shearar <frank.shearar(a)gmail.com>: >>>>> On 3 September 2011 18:50, Lukas Renggli <renggli(a)gmail.com> wrote: >>>>>> I think it is a good idea to have the number parser separate, after >>>>>> all it might also make sense to use it separately. >>>>>> >>>>>> It seems that the new Smalltalk grammar is significantly slower. The >>>>>> benchmark PPSmalltalkClassesTests class>>#benchmark: that uses the >>>>>> source code of the collection hierarchy and does not especially target >>>>>> number literals runs 30% slower. >>>>>> >>>>>> Also I see that "Number readFrom: ..." is still used within the >>>>>> grammar. This seems to be a bit strange, no? >>>>> >>>>> Yes: it's a double-parse, which is a bit lame. First, we parse the >>>>> literal with PPSmalltalkNumberParser, which ensures that the thing >>>>> given to Number class >> #readFrom: is a well-formed token (so, in >>>>> particular, Squeak's Number doesn't get to see anything other than a >>>>> well-formed token). >>>>> >>>>> It sounds like you're happy with the basic concept, so maybe I should >>>>> remove the Number class >> #readFrom: stuff, see if I can't remove the >>>>> performance issues, and resubmit the patch. >>>>> >>>>> frank >>>>> >>>> >>>> Yes, a NumberParser is essentially parsing, and this duplication sounds useless. >>>> The main feature of interest in NumberParser that I consider a >>>> requirement and should find its equivalence in a PetitNumberParser is: >>>> - round a decimal representation to nearest Float >>>> It's simple, just convert a Fraction asFloat in a single final step to >>>> avoid cumulating round off errors - see >>>> #makeFloatFromMantissa:exponent:base: >>>> >>>> The second feature of interest in NumberParser is the ability to >>>> parser LargeInteger efficiently by avoiding (10 * largeValue + >>>> digitValue) loops, and replacing them with a log(n) cost. >>>> This would be a simple thing to implement in a functional language. >>> >>> Hopefully this won't offend your sensibilities too much :). It does, >>> in fact, use 10* loops - I wrote an experimental "front half * rear >>> half" recursion, which was slower in my benchmarks. >>> >>> This version has the grammar and parser doing no string->number >>> conversion at all. PPSmalltalkNumberMaker supplies a number of utility >>> methods designed to stop one from making malformed numbers. It also >>> supplies a builder interface that the parser uses to construct >>> numbers. >>> >>> frank >>> >>>> Nicolas >>>> >>>>>> Lukas >>>>>> >>>>>> >>>>>> On 3 September 2011 17:18, Frank Shearar <frank.shearar(a)gmail.com> wrote: >>>>>>> On 3 September 2011 15:56, Lukas Renggli <renggli(a)gmail.com> wrote: >>>>>>>> On 3 September 2011 16:51, Frank Shearar <frank.shearar(a)gmail.com> wrote: >>>>>>>>> Hi Lukas, >>>>>>>>> >>>>>>>>> I haven't :) mainly because I'm unsure where to put it - is there >>>>>>>>> perhaps a PP Inbox, or shall I just post the merged version, or what's >>>>>>>>> your preference? (How about an mcd between my merge and PP's head?) >>>>>>>> >>>>>>>> Just put the .mcz at some public URL (dropbox, squeak source, ...) or >>>>>>>> attach it to a mail. >>>>>>> >>>>>>> Ah, great - here it is. You'll see I've written the grammar as a >>>>>>> separate class. That was really more to make what I'd done more >>>>>>> obvious and to minimise the change to PPSmalltalkGrammar, but perhaps >>>>>>> it's not a bad idea anyway: it's easy to see the number literal >>>>>>> subgrammar. >>>>>>> >>>>>>> frank >>>>>>> >>>>>>>> Lukas >>>>>>>> >>>>>>>> -- >>>>>>>> Lukas Renggli >>>>>>>> www.lukas-renggli.ch >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Lukas Renggli >>>>>> www.lukas-renggli.ch >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >> >> > >

Sept. 27, 2011

Re: [Pharo-project] Webservices (any update)

by StÃ©phane Ducasse

On Sep 27, 2011, at 9:06 AM, Torsten Bergmann wrote: > Whats used these days to connect to webservices using Pharo. > Is it possible to generate ST classes from a WSDL > and use them? Possible yes now there is no tools so far like in VW. > > Thx > T. > -- > Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir > belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de >

Sept. 27, 2011

[Pharo-project] Webservices (any update)

by Torsten Bergmann

Whats used these days to connect to webservices using Pharo. Is it possible to generate ST classes from a WSDL and use them? Thx T. -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

Sept. 27, 2011

Re: [Pharo-project] [ANN] Pharo Glorp port release

by Mariano Martinez Peck

> > So, thanks again to ESUG for sponsoring the project :). > > And thanks to Alan for all his help and effort in Glorp. > Guillermo, Santiago, Gisela, Mariano, Esteban and Diogenes > > -- > You received this message because you are subscribed to the Google Groups > "proyecto_relacional" group. > To post to this group, send email to proyecto_relacional(a)googlegroups.com. > To unsubscribe from this group, send email to > proyecto_relacional+unsubscribe(a)googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/proyecto_relacional?hl=en. > -- Mariano http://marianopeck.wordpress.com

Sept. 26, 2011

Re: [Pharo-project] new Cog VMs available...

by StÃ©phane Ducasse

Indeed. > Alas not in this case. The bug manifests itself when a cog code compaction occurs soon after an MNU PIC has been created and the symptom is a fatal crash. So a) it is very difficult to reproduce and b) there would be no neat test failure, there would be a core dump. Yes this is useful for a Jenkins context, but in general I think it better to test things like this with heavy stress tests (and general community usage) rather than trying to produce a specific test. Stef

Sept. 26, 2011

Re: [Pharo-project] google issue 3236

by StÃ©phane Ducasse

tx for the information On Sep 26, 2011, at 6:50 PM, Norbert Hartl wrote: > > Am 26.09.2011 um 18:19 schrieb StÃ©phane Ducasse: > >> sure it will > > Now I see why it wasn't integrated. The fix is not that easy as it is in the bug entry. > >> Now did you check the motivation? > > Of the issue? Of course, to get time information that contains milliseconds and not only seconds. > >> Was it good? > > I think yes. The milliSecondClock is nothing reliable. You need to fiddle with it to get a real millisecond value. > >> Worth to get it in? > > Yes, I need to be able to measure milliseconds. I could use milliSecondClock but I think it is good for pharo to integrate it into DateAndTime properly. > > Norbert > >> On Sep 26, 2011, at 5:24 PM, Norbert Hartl wrote: >> >>> >>> Am 26.09.2011 um 16:40 schrieb Marcus Denker: >>> >>>> >>>> On Sep 26, 2011, at 4:36 PM, Norbert Hartl wrote: >>>> >>>>> Does anybody know what happened to >>>>> >>>>> http://code.google.com/p/pharo/issues/detail?id=3236 >>>>> >>>>> In pharo-1.3 and pharo-1.4 they aren't in. Well, that matches the status of FixedWaitingToBePharoed. Last change by Marcus is from April 7th. >>>>> >>>> >>>> Every issue not closed has yet to be done. >>>> >>>> So the anwer is: Nothing happend. >>>> >>> Ok, >>> >>> there was only a diff so I guess it was more manual work to have it integrated. I'm redoing the stuff on a fresh 1.4 image so it can be easily integrated. I hope this will help getting it in. >>> >>> Norbert >>> >>> >>> >> >> > >

Sept. 26, 2011

Re: [Pharo-project] PetitSmalltalk: now with a self-contained grammar for number literals

by Eliot Miranda

On Sun, Sep 25, 2011 at 7:21 AM, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> wrote: > 2011/9/25 Frank Shearar <frank.shearar(a)gmail.com>: > > Nicolas, you'd mentioned a log_2 n implementation for number parsing. > > I think by that you mean the division of digits into two "packets" > > that are processed and then added? > > > > I tried a straight-forward fold (using the * 10 that you said you didn't > like!) > > > > Time millisecondsToRun: [10000 timesRepeat: > > ['123456789012345678901234567890' inject: 0 into: [:acc :each | 10 * > > acc + each digitValue]]] => 818 > > > > and what I think you meant: > > > > | f | > > f := 1. "Just to shut the compiler up about the self-reference." > > f := [:someDigits | | len | > > len := someDigits size. > > (len = 1) > > ifTrue: [someDigits first digitValue] > > ifFalse: [ | leftHalf rightHalf | > > leftHalf := someDigits first: len // 2. > > rightHalf := someDigits allButFirst: len // 2. > > ((f value: (leftHalf)) * (10 raisedTo: rightHalf > size)) + (f value: > > rightHalf)]]. > > Time millisecondsToRun: [10000 timesRepeat: [f value: > > '123456789012345678901234567890']] => 1508 > > > > I went with the straight-forward fold because it was simpler and my > > (quite possibly wrong/inefficient) attempt at a log_2 n version was a > > lot less readable. > > > > I'd greatly appreciate being gently corrected! > > > > frank > > > > Hmm, let's see. > > Suppose that SmallIntegers are on 3 digits, and Large begins at 4. > And let's compose a 32 digits number 12345678901234567890123456789012 > > If I do the naive loop the first 3 loops (6 ops) give small ints. > Then the next 29 loops (58 ops) are performed with large ints. > > Now, if I perform these ops: > > ((1234 * (10**4) + 5678) * (10**8) + (9012 * (10**4) + 3456)) * > (10**16) + ((7890 * (10**16) + 1234) * (10**8) + (5678 * (10**4) + > 9012)) > > This time, I have 24 loops with small int (48 ops) and 8 loops (16 > ops) with large ints for evaluating the 4 digits ints. > Plus 14 operations to assemble these large ints into the final result. > Plus a number of operations required to evaluate the powers of 10: > without cache, this is > > 10**4 = 10 squared squared (1 small op + 1 large) * 4 times. > 10**8 = 10 squared squared squared (1 small op + 2 large) * 2 times. > 10**16 = 10 squared squared squared (1 small op + 3 large) * 1 time. > > The total is 55 ops on small ints + 41 ops on large ints. > So the second algorithm costs more operations on total, but cheaper ones. > Suppose every operation on SmallInteger costs 1 and LargeInteger costs 10, > we have a cost of 586 for the first, 465 for the second. > > Also, the cost of Large int operations is not constant. > It is proportional to max(length1,length2) for + and to length1*length2 for > *. > So, we'll consider length(10**n)=n. > In first case, length2=1 and length1 is varying linearly between 4 and > 32, thus a mean of 18*2 digit ops per loop * 29 loops. > > In the second case, the cost in digit ops is: > 1) (3*1+4) per loop * 8 loops for forming the 4 digits elementary large > ints > 2) (4*4+8) per loop * 4 loops for forming the 8 digits large ints > 3) (8*8+16) per loop * 2 loops for forming the 16 digits large ints > 4) (16*16+32) for the last iteration > > Plus the costs of evaluating powers of 10: > 1) (100 squared) is evaluated 7 times * (2*2) digit ops > 2) (10000 squared) is evaluated 3 times * (4*4) digit ops > 3) (100000000 squared) is evaluated 1 times * (8*8) digit ops > > grand total is 18*2*29 = 1044 digit ops for the naive algorithm > For the divide and conquer form, that is ((3*1+4)*8) + ((4*4+8)*4) + > ((8*8+16)*2) + (16*16+32) + (2*2*7) + (4*4*3) + (8*8) = 740 > > In your 30 decimal digits example, large integers are formed of 10 > decimal digits (SmallInteger maxVal + 1) printString size, so we would > have to translate above count... > But it's boring, we can lazily bench it: > > | stream | > stream := '123456789012345678901234567890' readStream. > { > [stream reset; nextFloat] bench. > [stream reset. Number readFrom: stream] bench. > } > #('15,600 per second.' '23,500 per second.') "Old 4.2 VM" > #('56,100 per second.' '97,700 per second.') "recent COG VM" > Nice to see (since it is to be expected) that as the algorithm spends less time in LargeInteger primitives and more time in simple operations Cog provides more speedup over the interpreter. 56,100/15,600 =~ 3.6, 97,700/23,500 =~ 4.2. Stream>>nextFloat is a naive loop with almost every operation inlined. > Number>>readFrom: traverses a bunch of sends before the real > operations take place. > > The overhead equlibrates around 12 decimal digits in non COG VM ! > That's why it was already faster for scanning a 15 digits Float (non > counting the fact that nextFloat fails to answer the nearest Float). > Now, in COG, it equilibrates around 20 digits. > > If we want to draw the cost versus log of number of digits: > > | gen counts serie cost1 cost2 | > gen := Generator on: [:g | [g yield: '1234567890' atRandom] repeat]. > counts := (2 to: 13) collect: [:e | 2 raisedTo: e]. > serie := counts collect: [:count | > String withAll: (gen next: count)]. > cost1 := serie collect: [:e | > [1000 timesRepeat: [e readStream nextFloat]] timeToRun]. > cost2 := serie collect: [:e | > [1000 timesRepeat: [(Number readFrom: e readStream) asFloat]] > timeToRun]. > {counts. cost1. cost2.} > #("NON COG VM" > #(4 8 16 32 64 128 256 512 1024 2048 4096 8192) > #(2 2 25 65 146 304 647 1412 3288 8393 24021 77189) > #(6 6 21 51 94 177 361 742 1550 3872 8471 22647)) > > #("COG VM" > #(4 8 16 32 64 128 256 512 1024 2048 4096 8192) > #(0 2 3 20 56 139 334 838 2323 7010 23614 85925) > #(2 0 4 13 24 53 116 264 626 1646 4552 14191)) > > It's not a log_2 cost at the end, but it's already some gain. > It's possible that above costs are dominated by garbage collection, > but I don't know how to measure that accurately... > > Nicolas > > > On 14 September 2011 20:26, Frank Shearar <frank.shearar(a)gmail.com> > wrote: > >> On 3 September 2011 19:35, Nicolas Cellier > >> <nicolas.cellier.aka.nice(a)gmail.com> wrote: > >>> 2011/9/3 Frank Shearar <frank.shearar(a)gmail.com>: > >>>> On 3 September 2011 18:50, Lukas Renggli <renggli(a)gmail.com> wrote: > >>>>> I think it is a good idea to have the number parser separate, after > >>>>> all it might also make sense to use it separately. > >>>>> > >>>>> It seems that the new Smalltalk grammar is significantly slower. The > >>>>> benchmark PPSmalltalkClassesTests class>>#benchmark: that uses the > >>>>> source code of the collection hierarchy and does not especially > target > >>>>> number literals runs 30% slower. > >>>>> > >>>>> Also I see that "Number readFrom: ..." is still used within the > >>>>> grammar. This seems to be a bit strange, no? > >>>> > >>>> Yes: it's a double-parse, which is a bit lame. First, we parse the > >>>> literal with PPSmalltalkNumberParser, which ensures that the thing > >>>> given to Number class >> #readFrom: is a well-formed token (so, in > >>>> particular, Squeak's Number doesn't get to see anything other than a > >>>> well-formed token). > >>>> > >>>> It sounds like you're happy with the basic concept, so maybe I should > >>>> remove the Number class >> #readFrom: stuff, see if I can't remove the > >>>> performance issues, and resubmit the patch. > >>>> > >>>> frank > >>>> > >>> > >>> Yes, a NumberParser is essentially parsing, and this duplication sounds > useless. > >>> The main feature of interest in NumberParser that I consider a > >>> requirement and should find its equivalence in a PetitNumberParser is: > >>> - round a decimal representation to nearest Float > >>> It's simple, just convert a Fraction asFloat in a single final step to > >>> avoid cumulating round off errors - see > >>> #makeFloatFromMantissa:exponent:base: > >>> > >>> The second feature of interest in NumberParser is the ability to > >>> parser LargeInteger efficiently by avoiding (10 * largeValue + > >>> digitValue) loops, and replacing them with a log(n) cost. > >>> This would be a simple thing to implement in a functional language. > >> > >> Hopefully this won't offend your sensibilities too much :). It does, > >> in fact, use 10* loops - I wrote an experimental "front half * rear > >> half" recursion, which was slower in my benchmarks. > >> > >> This version has the grammar and parser doing no string->number > >> conversion at all. PPSmalltalkNumberMaker supplies a number of utility > >> methods designed to stop one from making malformed numbers. It also > >> supplies a builder interface that the parser uses to construct > >> numbers. > >> > >> frank > >> > >>> Nicolas > >>> > >>>>> Lukas > >>>>> > >>>>> > >>>>> On 3 September 2011 17:18, Frank Shearar <frank.shearar(a)gmail.com> > wrote: > >>>>>> On 3 September 2011 15:56, Lukas Renggli <renggli(a)gmail.com> wrote: > >>>>>>> On 3 September 2011 16:51, Frank Shearar <frank.shearar(a)gmail.com> > wrote: > >>>>>>>> Hi Lukas, > >>>>>>>> > >>>>>>>> I haven't :) mainly because I'm unsure where to put it - is there > >>>>>>>> perhaps a PP Inbox, or shall I just post the merged version, or > what's > >>>>>>>> your preference? (How about an mcd between my merge and PP's > head?) > >>>>>>> > >>>>>>> Just put the .mcz at some public URL (dropbox, squeak source, ...) > or > >>>>>>> attach it to a mail. > >>>>>> > >>>>>> Ah, great - here it is. You'll see I've written the grammar as a > >>>>>> separate class. That was really more to make what I'd done more > >>>>>> obvious and to minimise the change to PPSmalltalkGrammar, but > perhaps > >>>>>> it's not a bad idea anyway: it's easy to see the number literal > >>>>>> subgrammar. > >>>>>> > >>>>>> frank > >>>>>> > >>>>>>> Lukas > >>>>>>> > >>>>>>> -- > >>>>>>> Lukas Renggli > >>>>>>> www.lukas-renggli.ch > >>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> Lukas Renggli > >>>>> www.lukas-renggli.ch > >>>>> > >>>>> > >>>> > >>>> > >>> > >>> > >> > > > > > > -- best, Eliot

Sept. 26, 2011