Re: [Pharo-users] Spur images
On 10 Oct 2014, at 03:40, Benjamin Pollack benja...@bitquabit.com wrote: On Sun, 05 Oct 2014 16:51:25 -0400, Sven Van Caekenberghe s...@stfx.eu wrote: [snip] Apart from that, the tokenisation is not very efficient, #lines is a copy of your whole contents, so is the #split: and #trimmed. The algorithm sounds a bit lazy as well, writing it 'on purpose' with an eye for performance might yield better results. So I was reflecting on this more. If String and WideString were immutable, then it'd be easy to avoid all of these copies; you could instead pass around very tiny objects that had only three members (a String, a start position, a stop position), and avoid copying very much data. It's that String and WideString are mutable that preclude that. For fun, since I know I won't mutate the stringsin this example, I actually did a quick spike where I replaced #copyFrom:to: with a new method I introduced called #viewFrom:to: that returned a StringView. I'll post the code when I have a chance to clean it up if there's interest, but it looks like it pretty handedly chops off 120-150ms from that runtime (i.e., double the speed). Has there been any thought to introducing some immutable collections? Or maybe I'm just missing them? They'd be useful not just for String and WideString, but really for basically any of the collection types. The implementation in most cases would be as simple as overriding #at:put: and friends to throw self shouldNotImplement, and then providing methods/classes like the one I introduced to allow taking advantage of the newfound immutability. If there's interest, I'd be happy to submit a Slice we could use as a concrete RFC of what this could look like. --Benjamin I think it is interesting that you get real measurable improvements with user defined string views. I have always felt that a problem for going in that direction is that most primitives (which are important to get good basic string performance) are not flexible enough to be used really efficiently. More concretely, they should take start/stop indexes on all string arguments. For example, ByteString class#compare:with:collated: or #stringHash:initialHash: - it should be possible to do these operations on substrings *without creating the substrings*. Sven
Re: [Pharo-users] Spur images
Interesting. When working on AstroCloud (http://astrocloudy.wordpress.com) we find out that Bitmap and FormCanvas were way too slow. Performing a global modification (e.g., changing a red for a blue) took long long time for very large images (2000 x 2000 pixels). We did some intensive profiling and aggressive optimizations until the points we could not optimize anymore. We then tried to avoid manipulating objects in some very specific part of the code. For example, instead of having instance of the class Color, we have an array (unique and preallocated) that contains the red, green, and blue values. Having these “primitives” values was convenient to call either a C function or very low level functions with native boost. We got a ~ x 30 speed up. I do not know much about wide strings, but I suspect you can do something like that. So, my advice is: identify the method that cost you a lot, and write it natively. This has worked for us, in a non-trivial setting. Let us know Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. On Oct 3, 2014, at 5:07 PM, Benjamin Pollack benja...@bitquabit.com wrote: My apologies if this is already spelled out somewhere and I simply can't find it, but are there any Spur images for Pharo yet? I can only find Squeak ones. It's not a big deal either way; I was just playing with an algorithm that, after very heavy optimization, I was able to get down to about 278ms per pass (from ~700ms initially from a naive implementation). For contrast, the equivalent Python runs in ~80ms. Looking at MessageTally, it seems at least half of that 278ms is spent noodling around in WideStrings and other small things that the Spur object format ought to help with, so it'd be interesting to see how much of a speed boost that gives without any further work.
Re: [Pharo-users] Spur images
On Sun, 05 Oct 2014 16:51:25 -0400, Sven Van Caekenberghe s...@stfx.eu wrote: [snip] Apart from that, the tokenisation is not very efficient, #lines is a copy of your whole contents, so is the #split: and #trimmed. The algorithm sounds a bit lazy as well, writing it 'on purpose' with an eye for performance might yield better results. So I was reflecting on this more. If String and WideString were immutable, then it'd be easy to avoid all of these copies; you could instead pass around very tiny objects that had only three members (a String, a start position, a stop position), and avoid copying very much data. It's that String and WideString are mutable that preclude that. For fun, since I know I won't mutate the stringsin this example, I actually did a quick spike where I replaced #copyFrom:to: with a new method I introduced called #viewFrom:to: that returned a StringView. I'll post the code when I have a chance to clean it up if there's interest, but it looks like it pretty handedly chops off 120-150ms from that runtime (i.e., double the speed). Has there been any thought to introducing some immutable collections? Or maybe I'm just missing them? They'd be useful not just for String and WideString, but really for basically any of the collection types. The implementation in most cases would be as simple as overriding #at:put: and friends to throw self shouldNotImplement, and then providing methods/classes like the one I introduced to allow taking advantage of the newfound immutability. If there's interest, I'd be happy to submit a Slice we could use as a concrete RFC of what this could look like. --Benjamin
[Pharo-users] Spur images
My apologies if this is already spelled out somewhere and I simply can't find it, but are there any Spur images for Pharo yet? I can only find Squeak ones. It's not a big deal either way; I was just playing with an algorithm that, after very heavy optimization, I was able to get down to about 278ms per pass (from ~700ms initially from a naive implementation). For contrast, the equivalent Python runs in ~80ms. Looking at MessageTally, it seems at least half of that 278ms is spent noodling around in WideStrings and other small things that the Spur object format ought to help with, so it'd be interesting to see how much of a speed boost that gives without any further work.
Re: [Pharo-users] Spur images
Pharo has a new classbuilder with first class instance variables so the bootstrap took longer and doing so esteban and guille found bugs in Spur. So regularly but hidden from the fame, esteban goes over it. and we hope soon to have some images to beta testers. My apologies if this is already spelled out somewhere and I simply can't find it, but are there any Spur images for Pharo yet? I can only find Squeak ones. It's not a big deal either way; I was just playing with an algorithm that, after very heavy optimization, I was able to get down to about 278ms per pass (from ~700ms initially from a naive implementation). For contrast, the equivalent Python runs in ~80ms. Looking at MessageTally, it seems at least half of that 278ms is spent noodling around in WideStrings and other small things that the Spur object format ought to help with, so it'd be interesting to see how much of a speed boost that gives without any further work. tell us more about your algo because we want to know.
Re: [Pharo-users] Spur images
as Stef says, we are close, but not there yet. I’m working on it and I hope to have something really soon. Esteban On 03 Oct 2014, at 22:13, stepharo steph...@free.fr wrote: Pharo has a new classbuilder with first class instance variables so the bootstrap took longer and doing so esteban and guille found bugs in Spur. So regularly but hidden from the fame, esteban goes over it. and we hope soon to have some images to beta testers. My apologies if this is already spelled out somewhere and I simply can't find it, but are there any Spur images for Pharo yet? I can only find Squeak ones. It's not a big deal either way; I was just playing with an algorithm that, after very heavy optimization, I was able to get down to about 278ms per pass (from ~700ms initially from a naive implementation). For contrast, the equivalent Python runs in ~80ms. Looking at MessageTally, it seems at least half of that 278ms is spent noodling around in WideStrings and other small things that the Spur object format ought to help with, so it'd be interesting to see how much of a speed boost that gives without any further work. tell us more about your algo because we want to know.
