- Pharo-dev - lists.pharo.org

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/40375 Home: https://github.com/pharo-project/pharo-core

Nov. 19, 2014

[pharo-project/pharo-core] f975b8: 40375

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: f975b8237543dfff34d8eaec787c1a9494e07bc2 https://github.com/pharo-project/pharo-core/commit/f975b8237543dfff34d8eaec… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-11-19 (Wed, 19 Nov 2014) Changed paths: A NewValueHolder.package/extension/OrderedDictionary/instance/asValueHolder.st M OpalCompiler-Core.package/OpalCompiler.class/instance/public access/decompileMethod_.st A OpalCompiler-Core.package/extension/RBMethodNode/class/errorMethodNode_errorMessage_.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script375.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40375.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 40375 14496 Emergency tool instead of the debugger starting (caused by issue #14469 in update #40373) https://pharo.fogbugz.com/f/cases/14496 14492 OpalCompiler depends on OpalDecompiler https://pharo.fogbugz.com/f/cases/14492 http://files.pharo.org/image/40/40375.zip

Nov. 19, 2014

Re: [Pharo-dev] Can we make this fast ?

by phil＠highoctane.be

On Wed, Nov 19, 2014 at 12:33 AM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > On Tue, Nov 18, 2014 at 3:24 PM, phil(a)highoctane.be <phil(a)highoctane.be> > wrote: > >> >> Le 18 nov. 2014 22:52, "Sven Van Caekenberghe" <sven(a)stfx.eu> a Ã©crit : >> >> > >> > >> > > On 18 Nov 2014, at 22:28, Andreas Wacknitz <A.Wacknitz(a)gmx.de> wrote: >> > > >> > > >> > > Am 18.11.14 22:12, schrieb phil(a)highoctane.be: >> > >> See >> > >> https://news.ycombinator.com/item?id=8625280 >> > >> >> > >> [ (1 to: 100000000) sum ] timeToRun >> > >> >> > >> Here we get out of the SmallInteger range... >> > >> >> > >> Apart FFI'ing the thing, do we have other options? >> > >> >> > >> Phil >> > > Choose a better algorithm: >> > > [100000000 * 10000001 / 2] timeToRun >> > > should beat yours by several orders of magnitude. >> > > >> > > Andreas >> > >> > Haha, great ! >> > >> > >> >> Sure cool. >> >> Now Pharo is slow on these loops with arithmetics and it is painful. >> > > Yes, but that particular loop is low because in part it uses the sum > convenience. e.g. > > Collection>>sum > "Compute the sum of all the elements in the receiver" > > ^self reduce:[:a :b| a + b] > > Collection>>reduce: binaryBlock > "Apply the argument, binaryBlock cumulatively to the elements of the > receiver. > For sequenceable collections the elements will be used in order, for > unordered > collections the order is unspecified." > > | first nextValue | > first := true. > self do: [ :each | > first > ifTrue: [ nextValue := each. first := false ] > ifFalse: [ nextValue := binaryBlock value: nextValue value: each ] ]. > first ifTrue: [ self errorEmptyCollection ]. > ^nextValue > I see that in Squeak 4.5. Interestingly, Pharo (here 3.0) has a different implementation. Collection>>sum sum "This is implemented using a variant of the normal inject:into: pattern. The reason for this is that it is not known whether we're in the normal number line, i.e. whether 0 is a good initial value for the sum. Consider a collection of measurement objects, 0 would be the unitless value and would not be appropriate to add with the unit-ed objects." | sum sample | sample := self anyOne. sum := self inject: sample into: [:accum :each | accum + each]. ^ sum - sample and reduce: is: Collection>>reduce: aBlock "Fold the result of the receiver into aBlock. The argument aBlock must take two or more arguments. It applies the argument, binaryBlock cumulatively to the elements of the receiver. For sequenceable collections the elements will be used in order, for unordered collections the order is unspecified." "#(1 2 3) asSet reduce: [ :a :b | a + b ] --> 1 + 2 + 3 = 6 #(1 2 3 4 5) asSet reduce: [ :a :b :c | a + b + c ] --> 1 + 2 + 3 + 4 + 5 = 15" ^self asOrderedCollection reduce: aBlock Which in SequencableCollection>>reduce: aBlock is reduce: aBlock "Fold the result of the receiver into aBlock. The argument aBlock must take two or more arguments. It applies the argument, binaryBlock cumulatively to the elements of the receiver. For sequenceable collections the elements will be used in order, for unordered collections the order is unspecified." "#(1 2 3) reduce: [ :a :b | a + b ] --> 1 + 2 + 3 = 6 #(1 2 3 4 5) reduce: [ :a :b :c | a + b + c ] --> 1 + 2 + 3 + 4 + 5 = 15" ^ self reduceLeft: aBlock where reduceLeft: aBlock is reduceLeft: aBlock "Fold the result of the receiver from left to right into aBlock. The argument aBlock must take two or more arguments." "#(1 2 3) reduceLeft: [ :a :b | a - b ]. --> ((1 - 2) - 3) = -4 #(1 + 3 - 5) reduceLeft: [ :a :op :b | a perform: op with: b ]. --> ((1 + 3) - 5) = -1" | arguments | self emptyCheck. arguments := Array new: aBlock argumentCount. (arguments size = 0 or: [ (self size + 1) \\ (arguments size - 1) > 0 ]) ifTrue: [ self error: 'Collection size and block argument count do not match.' ]. arguments at: 1 put: self first. 2 to: self size by: arguments size - 1 do: [ :index | arguments replaceFrom: 2 to: arguments size with: self startingAt: index; at: 1 put: (aBlock valueWithArguments: arguments) ]. ^ arguments first That's quite a different way to look at things implementation wise. Why those changes? > > | n | > n := 100000000. > { [ (1 to: n) sum ] timeToRun. [| s | s := 0. (1 to: n) do: [:i| s := s + > i]] timeToRun. [| s | s := 0. 1 to: n do: [:i| s := s + i]] timeToRun. [n * > (n + 1) / 2] timeToRun} > > #(10112 9538 8432 0) > Pharo 3.0 gives: Array(0:00:00:06.916 0:00:00:06.303 0:00:00:05.647 0:00:00:00) Squeak 4.5 gives: #(8211 7844 6875 0) Interestingly, the Pharo timeToRun is the Squeak durationToRun. | n | n := 100000000. { [ (1 to: n) sum ] durationToRun. [| s | s := 0. (1 to: n) do: [:i| s := s + i]] durationToRun. [| s | s := 0. 1 to: n do: [:i| s := s + i]] durationToRun. [n * (n + 1) / 2] durationToRun} {0:00:00:08.271 . 0:00:00:07.9 . 0:00:00:06.94 . 0:00:00:00} Printout formats are also different :-) So: Pharo 3.0 (0:00:00:06.916 0:00:00:06.303 0:00:00:05.647 0:00:00:00) Squeak 4.5 {0:00:00:08.271 0:00:00:07.900 0:00:00:06.940 . 0:00:00:00} I tried it out on VW 7.10PUL 32bits: | n | n := 100000000. "[(1 to: n) sum ] timeToRun." [| s | s := 0. 1 to: n do: [:i| s := s + i]] timeToRun. 5.766674 seconds I tried it out on VW 7.10PUL 64bits: There is no sum in Collection as far as I can see. | n | n := 100000000. "[(1 to: n) sum ] timeToRun." [| s | s := 0. (1 to: n) do: [:i| s := s + i]] timeToRun. 3.171995 seconds | n | n := 100000000. "[(1 to: n) sum ] timeToRun." [| s | s := 0. 1 to: n do: [:i| s := s + i]] timeToRun. 235.993 milliseconds Impressive!!! Hope we get that with the 64 bit VM too. last case, 0 of course. Eliot, why is a class variable faster? >> > > The expression is a constant. You can e.g. compute it at class > initialization and for descriptive purposes store the result in a class > variable. That's usually quicker than computing anything every time. > Standard examples are specialized dispatch tables, dictionaries, etc. > Class variables are a convenient way of holding onto precomputed objects. > Thank you. > > Alex, I'll a look at OpenCL. >> >> Also, I tried with a whileTrue: loop which was 3 times faster than the >> sum on Collection. >> >> How to profile these kinds of tight loops? The standard profiler is kind >> of useless. >> Is AndreasProfiler the way to go >> > IMO yes. It is much more accurate about primitives than the standard > profiler. > Thx. Phil > -- > best, > Eliot >

Nov. 19, 2014

Re: [Pharo-dev] Pharo contributions server gone

by Marcus Denker

> On 18 Nov 2014, at 22:07, Torsten Bergmann <astares(a)gmx.de> wrote: > > https://ci.inria.fr/pharo-contribution > > > Restart? > Done. We really need a watchdog that restarts automatically. One of the things that not many people understand: most âvery reliableâ systems are actually not reliable, they just react well to failure (e.g. restarting automatically). Marcus

Nov. 19, 2014

Re: [Pharo-dev] Emergency tool instead of the debugger starting (caused by issue #14469 in update #40373)

by Marcus Denker

> On 19 Nov 2014, at 01:05, Torsten Bergmann <astares(a)gmx.de> wrote: > > The expression > > 1 halt > > or any other part that has to be debugged gives the emergency tool > instead of the debugger. > > Pharo 4.0 #40372 image is working (gives the usual debugger) > Pharo 4.0 #40373 image not working (emergency evaluator) > > The problem seems to be related to the fix/slice > "SLICE-Issue-14469-Merge-back-OrderPreservingDictionary-improvements-MarcusDenker.1" > for issue 14469. > > When one manually merges the slice from issue #14469 into Pharo 4.0 #40372 > one can reproduce this problem. > OrderedDictionary is missing: asValueHolder ^ DictionaryValueHolder value: self (OrderedIdentityDictionary used to be a subclass of Dictionary, which has this) Marcus

Nov. 19, 2014

Re: [Pharo-dev] [Vm-dev] Re: Spur 64-bits. Ugh, this could be a slog...

by David T. Lewis

On Tue, Nov 18, 2014 at 07:59:30PM -0800, Ryan Macnak wrote: > > What about bytecode pc's? These are indexed based on the physical size of > the literals. I don't like the idea of debugging pc -> source mappings, pc > coverage data, etc needing invalidation after starting an image on a > platform with a different word size. I may be misunderstanding your question, but I do not think that this will be an issue. All byte addressible objects need to work properly in any image, including 32 and 64 bit images. If that part does not work, then the image will not run, so no problem ;-) With respect to platform word size (e.g. 64 bit OS versus 32 bit OS), the images should all run bit-identically regardless of platform word size. A 64-bit image can (and does) run on a 32-bit host platform, given a suitably compiled VM. And a 32-bit image will run on a 64-bit host platform, given a suitably compiled VM (or more commonly, a 32-bit VM with 32-bit compatibility libraries installed on the platform). Dave > > On Tue, Nov 18, 2014 at 7:12 PM, Eliot Miranda <eliot.miranda(a)gmail.com> > wrote: > > > Hi All, > > > > I'm making good progress on 64-bit Spur in the Stack VM simulator. > > But I've just noticed an image-level issue which could be indicative of > > lots of 32-bit assumptions baked into the Squeal/Pharo/Newspeak systems. > > > > SmallInteger>>digitAt: n > > "Answer the value of an indexable field in the receiver. > > LargePositiveInteger uses bytes of base two number, and each is a 'digit' > > base 256. Fail if the argument (the index) is not an Integer or is out of > > bounds." > > n>4 ifTrue: [^ 0]. > > self < 0 > > ifTrue: > > [self = SmallInteger minVal ifTrue: > > ["Can't negate minVal -- treat specially" > > ^ #(0 0 0 64) at: n]. > > ^ ((0-self) bitShift: (1-n)*8) bitAnd: 16rFF] > > ifFalse: [^ (self bitShift: (1-n)*8) bitAnd: 16rFF] > > > > This assumes that SmallInteger is only ever 4 bytes, which is unacceptably > > wasteful for my approach to 64-bits. In 64-bit Spur, SmallIntegers are > > 61-bit 2's complement. > > > > I'm raising this example at this point to see if the community might find > > similar issues and bring them to my attention. > > -- > > best, > > Eliot > >

Nov. 19, 2014

Re: [Pharo-dev] [Vm-dev] Spur 64-bits. Ugh, this could be a slog...

by David T. Lewis

On Tue, Nov 18, 2014 at 07:12:12PM -0800, Eliot Miranda wrote: > > Hi All, > > I'm making good progress on 64-bit Spur in the Stack VM simulator. But > I've just noticed an image-level issue which could be indicative of lots of > 32-bit assumptions baked into the Squeal/Pharo/Newspeak systems. > > SmallInteger>>digitAt: n > "Answer the value of an indexable field in the receiver. > LargePositiveInteger uses bytes of base two number, and each is a 'digit' > base 256. Fail if the argument (the index) is not an Integer or is out of > bounds." > n>4 ifTrue: [^ 0]. > self < 0 > ifTrue: > [self = SmallInteger minVal ifTrue: > ["Can't negate minVal -- treat specially" > ^ #(0 0 0 64) at: n]. > ^ ((0-self) bitShift: (1-n)*8) bitAnd: 16rFF] > ifFalse: [^ (self bitShift: (1-n)*8) bitAnd: 16rFF] > > This assumes that SmallInteger is only ever 4 bytes, which is unacceptably > wasteful for my approach to 64-bits. In 64-bit Spur, SmallIntegers are > 61-bit 2's complement. > > I'm raising this example at this point to see if the community might find > similar issues and bring them to my attention. There will be quite a few issues like this scattered throughout the image. My suggestion would be to focus first on getting the 64-bit Spur image running with no changes to SmallInteger minVal and maxVal. Then, as a separate follow up step, expand the range of SmallInteger in the image and work out all the changes required to support it. Another possible way to attack the problem is to start with a Squeak trunk image in 68002 image format (64-bit image), and work out the issues associated with extending SmallInteger minVal and maxVal to take advantage of the larger immediate integers range. This could be independent of the work you are doing now, so if someone else wanted to work on the "expand range of SmallInteger" aspect of the project, I expect that this can be done in the existing 68002 image, such that the resulting changes would be directly applicable to the format 68019 (64-bit) Spur images. Dave

Nov. 19, 2014

Spur 64-bits. Ugh, this could be a slog...

by Eliot Miranda

Hi All, I'm making good progress on 64-bit Spur in the Stack VM simulator. But I've just noticed an image-level issue which could be indicative of lots of 32-bit assumptions baked into the Squeal/Pharo/Newspeak systems. SmallInteger>>digitAt: n "Answer the value of an indexable field in the receiver. LargePositiveInteger uses bytes of base two number, and each is a 'digit' base 256. Fail if the argument (the index) is not an Integer or is out of bounds." n>4 ifTrue: [^ 0]. self < 0 ifTrue: [self = SmallInteger minVal ifTrue: ["Can't negate minVal -- treat specially" ^ #(0 0 0 64) at: n]. ^ ((0-self) bitShift: (1-n)*8) bitAnd: 16rFF] ifFalse: [^ (self bitShift: (1-n)*8) bitAnd: 16rFF] This assumes that SmallInteger is only ever 4 bytes, which is unacceptably wasteful for my approach to 64-bits. In 64-bit Spur, SmallIntegers are 61-bit 2's complement. I'm raising this example at this point to see if the community might find similar issues and bring them to my attention. -- best, Eliot

Nov. 19, 2014

Emergency tool instead of the debugger starting (caused by issue #14469 in update #40373)

by Torsten Bergmann

The expression 1 halt or any other part that has to be debugged gives the emergency tool instead of the debugger. Pharo 4.0 #40372 image is working (gives the usual debugger) Pharo 4.0 #40373 image not working (emergency evaluator) The problem seems to be related to the fix/slice "SLICE-Issue-14469-Merge-back-OrderPreservingDictionary-improvements-MarcusDenker.1" for issue 14469. When one manually merges the slice from issue #14469 into Pharo 4.0 #40372 one can reproduce this problem. https://pharo.fogbugz.com/f/cases/14496

Nov. 19, 2014

Re: [Pharo-dev] Can we make this fast ?

by Eliot Miranda

On Tue, Nov 18, 2014 at 3:24 PM, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > > Le 18 nov. 2014 22:52, "Sven Van Caekenberghe" <sven(a)stfx.eu> a Ã©crit : > > > > > > > > On 18 Nov 2014, at 22:28, Andreas Wacknitz <A.Wacknitz(a)gmx.de> wrote: > > > > > > > > > Am 18.11.14 22:12, schrieb phil(a)highoctane.be: > > >> See > > >> https://news.ycombinator.com/item?id=8625280 > > >> > > >> [ (1 to: 100000000) sum ] timeToRun > > >> > > >> Here we get out of the SmallInteger range... > > >> > > >> Apart FFI'ing the thing, do we have other options? > > >> > > >> Phil > > > Choose a better algorithm: > > > [100000000 * 10000001 / 2] timeToRun > > > should beat yours by several orders of magnitude. > > > > > > Andreas > > > > Haha, great ! > > > > > > Sure cool. > > Now Pharo is slow on these loops with arithmetics and it is painful. > Yes, but that particular loop is low because in part it uses the sum convenience. e.g. Collection>>sum "Compute the sum of all the elements in the receiver" ^self reduce:[:a :b| a + b] Collection>>reduce: binaryBlock "Apply the argument, binaryBlock cumulatively to the elements of the receiver. For sequenceable collections the elements will be used in order, for unordered collections the order is unspecified." | first nextValue | first := true. self do: [ :each | first ifTrue: [ nextValue := each. first := false ] ifFalse: [ nextValue := binaryBlock value: nextValue value: each ] ]. first ifTrue: [ self errorEmptyCollection ]. ^nextValue | n | n := 100000000. { [ (1 to: n) sum ] timeToRun. [| s | s := 0. (1 to: n) do: [:i| s := s + i]] timeToRun. [| s | s := 0. 1 to: n do: [:i| s := s + i]] timeToRun. [n * (n + 1) / 2] timeToRun} #(10112 9538 8432 0) > Eliot, why is a class variable faster? > The expression is a constant. You can e.g. compute it at class initialization and for descriptive purposes store the result in a class variable. That's usually quicker than computing anything every time. Standard examples are specialized dispatch tables, dictionaries, etc. Class variables are a convenient way of holding onto precomputed objects. Alex, I'll a look at OpenCL. > > Also, I tried with a whileTrue: loop which was 3 times faster than the sum > on Collection. > > How to profile these kinds of tight loops? The standard profiler is kind > of useless. > Is AndreasProfiler the way to go > IMO yes. It is much more accurate about primitives than the standard profiler. -- best, Eliot

Nov. 18, 2014