Absolute beginner playing with smalltalk. I have a simple program that opens a number of text files, plays with data closes files and gives a count of things in the files. (Its actually my Squeak version of the Cincom VW Tutorial). I have run it on Squeak, Pharo and Cuis images. What suprised me was the difference in speeds. I haven't done tried to time it (I should do that or at least work out how to) but Squeak and Pharo take about the same time whereas Cuis is significantly quicker. I know its a cut down image but the difference is remarkable. Is this to be expected?
John _______________________________________________ Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
On 11/11/09 8:38 AM, "John Worden" <[hidden email]> wrote: Absolute beginner playing with smalltalk. I have a simple program that opens a number of text files, plays with data closes files and gives a count of things in the files. (Its actually my Squeak version of the Cincom VW Tutorial). I have run it on Squeak, Pharo and Cuis images. What suprised me was the difference in speeds. I haven't done tried to time it (I should do that or at least work out how to) but Squeak and Pharo take about the same time whereas Cuis is significantly quicker. I know its a cut down image but the difference is remarkable. Is this to be expected? Absolute yes. Like to know exact test for see how my own forks measures with Juan Vuletich Cuis. Edgar _______________________________________________ Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
In reply to this post by JRW
I am not absolutely sure, but I think CUIS translates methods into native code instead of bytecodes. Don't take my word for this, please.
Let someone else confirm it. It is something I heard some time ago.
On Wed, Nov 11, 2009 at 11:38, John Worden <[hidden email]> wrote: Absolute beginner playing with smalltalk. I have a simple program that opens a number of text files, plays with data closes files and gives a count of things in the files. (Its actually my Squeak version of the Cincom VW Tutorial). I have run it on Squeak, Pharo and Cuis images. What suprised me was the difference in speeds. I haven't done tried to time it (I should do that or at least work out how to) but Squeak and Pharo take about the same time whereas Cuis is significantly quicker. I know its a cut down image but the difference is remarkable. Is this to be expected? _______________________________________________ Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
In reply to this post by JRW
I am not absolutely sure, but I think CUIS translates methods to native code, instead of bytecodes, thus executing faster.
On Wed, Nov 11, 2009 at 11:38, John Worden <[hidden email]> wrote: Absolute beginner playing with smalltalk. I have a simple program that opens a number of text files, plays with data closes files and gives a count of things in the files. (Its actually my Squeak version of the Cincom VW Tutorial). I have run it on Squeak, Pharo and Cuis images. What suprised me was the difference in speeds. I haven't done tried to time it (I should do that or at least work out how to) but Squeak and Pharo take about the same time whereas Cuis is significantly quicker. I know its a cut down image but the difference is remarkable. Is this to be expected? _______________________________________________ Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
In reply to this post by JRW
Hi John,
JW> Absolute beginner playing with smalltalk. I have a simple JW> program that opens a number of text files, plays with data closes JW> files and gives a count of things in the files. (Its actually my JW> Squeak version of the Cincom VW Tutorial). I have run it on JW> Squeak, Pharo and Cuis images. What suprised me was the difference JW> in speeds. I haven't done tried to time it (I should do that or in case you don't know how: Time millisecondsToRun: [your code goes here] returns what it says. JW> at least work out how to) but Squeak and Pharo take about the same JW> time whereas Cuis is significantly quicker. I know its a cut down JW> image but the difference is remarkable. Is this to be expected? If you talk about files, a significant part of the time might be spent in the OS which depends on cacheing. So unless there is significant processing, file access might dominate (and invalidate) the measured times. Cuis has removed and cleaned up things which tends to speed things up but usually not to a noticeable degree. Even if you hit a significantly sped up method, such results should not be generalized. Cuis is not advertised for higher speed but for cleaner code, less bulk and better looks. IMHO that is. -- Cheers, Herbert _______________________________________________ Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
In reply to this post by JRW
On 11.11.2009, at 11:38, John Worden wrote: Absolute beginner playing with smalltalk. I have a simple program that opens a number of text files, plays with data closes files and gives a count of things in the files. (Its actually my Squeak version of the Cincom VW Tutorial). I have run it on Squeak, Pharo and Cuis images. What suprised me was the difference in speeds. I haven't done tried to time it (I should do that or at least work out how to) but Squeak and Pharo take about the same time whereas Cuis is significantly quicker. I know its a cut down image but the difference is remarkable. Is this to be expected? To a certain extent, yes. I'd suspect the unicode-support, which Cuis does not have, but Squeak and Pharo do. You would have to turn that off explicitly in Squeak if you care about performance. - Bert - _______________________________________________ Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
In reply to this post by Herbert König
Thanks Herbert for tip on timing.
For interest I tried. The results were. Squeak 5600 - 5800 milliseconds Pharo 5400 - 5500 milliseconds Cuis 200 - 500 milliseconds
So there was a factor of 10 in it which I why I noticed I guess. 2009/11/12 Herbert König <[hidden email]> Hi John, _______________________________________________ Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
Hi John,
JW> For interest I tried. The results were. JW> Squeak 5600 - 5800 milliseconds JW> Pharo 5400 - 5500 milliseconds JW> Cuis 200 - 500 milliseconds JW> So there was a factor of 10 in it which I why I noticed I guess. this is significant so I'm very curious what accounts for the difference. Would you mind to send me the Squeak version or post it here? -- Cheers, Herbert _______________________________________________ Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
Herbert,
I will email you the file and the data files its reading. If there is something of interest to others you can then post up the part matters. John
2009/11/14 Herbert König <[hidden email]> Hi John, _______________________________________________ Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
In reply to this post by JRW
On Friday 13 November 2009 04:05:08 pm John Worden wrote:
> Squeak 5600 - 5800 milliseconds > Pharo 5400 - 5500 milliseconds > Cuis 200 - 500 milliseconds > > So there was a factor of 10 in it which I why I noticed I guess. You may want to drill down the timing differences using: MessageTally spyOn: [ .... ] or TimeProfileBrowser spyOn: [ ... ] This will give you detailed breakup of time spent in message sends and the memory stress. Squeak and Pharo images are much bigger than Cuis so they may take up a larger portion of the memory resulting in frequent calls to GC. If you notice a difference in GC calls, you may want to repeat the trials with larger memory for the larger images. Subbu _______________________________________________ Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
In reply to this post by JRW
John,
JW> I will email you the file and the data files its reading. If thanks. JW> there is something of interest to others you can then post up the JW> part matters. I used TimeProfileBrowser (as Subbu suggested) and Squeak 3.8.2 (supporting UTF8) in comparison to Squeak 3.6 (which is pre Cuis). As Bert suggested, in more recent Squeaks a lot of time is spent in UTF8 decoding. My figures are 9300ms (3.8) vs. 480ms (3.6). In 3.6 significant time is spent in displaying the results on the Transcript. If I comment out that line in getLogFiles I'm down to 312ms. Which again shows the value of profiling before optimizing :-)) For unknown reasons in Cuis FileDirectory>>fileNames returns an empty Array so I can't try there. Cheers, Herbert _______________________________________________ Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
So are you saying that my example is slow because of the time taken to process the text data files in Squeak? (I was using 3.10)
Not that it matters in this case but how would I work around this if it were a real application that needed to handle data in this way?
John 2009/11/15 Herbert König <[hidden email]> John, _______________________________________________ Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
Hi John,
JW> So are you saying that my example is slow because of the time JW> taken to process the text data files in Squeak? (I was using 3.10) definitely, 90% of the time is spent in MultiByteFileStream>>upTo which is sent in WebLog>>showHits. JW> Not that it matters in this case but how would I work around JW> this if it were a real application that needed to handle data in JW> this way? First: really try TimeProfileBrowser spyOn: [WebLog new start ] and learn to interpret the results. No offense intended! Speed measurements are tricky but starting to optimize for speed without having measured usually will get you nowhere. You need to clearly understand where your time goes. Then you can know where to optimize. There is no general solution and it all depends on the real application. All that said, from the top of my head for this special case: -If your text data are UTF8, read the file binary and do some optimized processing on binary data. It will be far less elegant. -Disable UTF8 support as Bert suggested (never tried) if you can live with the consequences (or use Cuis). As far as I scanned the files there is no multi byte character in them. -Use some language better suited to the task to do some preprocessing. Cheers, Herbert _______________________________________________ Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
In reply to this post by JRW
On 14.11.2009, at 23:07, John Worden wrote: > So are you saying that my example is slow because of the time taken to process the text data files in Squeak? (I was using 3.10) > > Not that it matters in this case but how would I work around this if it were a real application that needed to handle data in this way? > > John If you do, e.g., FileStream readOnlyFileNamed: myFileName it creates a MultiByteFileStream nowadays (see #concreteStream). It would be nice if we could just set a no-op converter in a MultiByteFileStream. However, that class has not been optimized for speed yet, even without an expensive converter it is much slower. It reads characters one-by-one instead of block-wise, which obviously isn't speedy exactly, as you noticed. Instead of the abstract FileStream use the stream class you want explicitly. StandardFileStream is the old class that does no conversion. So you would open your file like this instead: StandardFileStream readOnlyFileNamed: myFileName - Bert - _______________________________________________ Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
Thanks to all.
Interesting and educational.
John
On Mon, Nov 16, 2009 at 12:17 AM, Bert Freudenberg <[hidden email]> wrote:
_______________________________________________ Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
I made the changes suggested by Bert and used StandardFileStream. Yes it fixes the speed issue.
As I said previously this has been interesting but it does leave me with mixed feelings which while off topic Ill express. As I said at the start of this I am a beginner. I can write a simple program and make it work and have done (PHP/Python/VisBasic/VBA).
I came to Squeak/Smalltalk and started having a play. There is something addictive about it but at the same time there are things like the speed issue above that don't make it "easy" for the learner. As an exercise I started to convert the excellent Cincom VW Tutorial to work in Squeak and at the same time I was converting it into Python. End result is that I had less difficulty getting it to work in Python than simply converting to Squeak. I wasn't expecting that. (For interest the other big problem I had, in addition to the speed one, was with the CrLf handling)
I am not trying to compare one language to another. Neither is it a judgement call on whats right or wrong all have their fit I'm sure. My question is whether people feel Squeak really is suitable for someone who just enjoys scripting simple programs? I can see the value in it from an educational perspective but for someone like me (who to be honest doesn't even want to worry about what things like UTF8 Support are all about) is it a good choice?
John
On Mon, Nov 16, 2009 at 8:26 AM, John Worden <[hidden email]> wrote:
_______________________________________________ Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
In reply to this post by Bert Freudenberg
At Sun, 15 Nov 2009 14:17:41 +0100,
Bert Freudenberg wrote: > > Instead of the abstract FileStream use the stream class you want explicitly. StandardFileStream is the old class that does no conversion. So you would open your file like this instead: > > StandardFileStream readOnlyFileNamed: myFileName Alternatively, if it is reading the entire file knowing that it is not encoded, you can say: (FileStream readOnlyFileNamed: myFileName) binary contentsOfEntireFile asString -- Yoshiki _______________________________________________ Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
In reply to this post by JRW
John Worden wrote:
> I came to Squeak/Smalltalk and started having a play. There is > something addictive about it but at the same time there are things like > the speed issue above that don't make it "easy" for the learner. As an > exercise I started to convert the excellent Cincom VW Tutorial to work > in Squeak and at the same time I was converting it into Python. End > result is that I had less difficulty getting it to work in Python than > simply converting to Squeak. I wasn't expecting that. (For interest the > other big problem I had, in addition to the speed one, was with the CrLf > handling) Which tutorial were you using? Cheers, - Andreas _______________________________________________ Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
In reply to this post by JRW
On Monday 16 November 2009 07:07:56 am John Worden wrote:
> My > question is whether people feel Squeak really is suitable for someone who > just enjoys scripting simple programs? Squeak is a scripting environment and there are many people who enjoy scripting in it, so if you are asking for a possibility the answer is Yes. But the choice is very personal and depends on your approach to solving problems. Smalltalk does not have any layers/barriers and allows one to 'tinker' freely. I also learnt (the hard way :-() that Squeak cannot be learnt easily from books because of their linear presentation styles. The best way to learn Squeak is to adopt a lateral, non-linear (as in Chess) and use Squeak itself as a living book. BTW, the fact that you were able to drill down to a specific performance bottleneck so quickly shows the power of Squeak. Subbu _______________________________________________ Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
In reply to this post by JRW
On Sun, Nov 15, 2009 at 7:37 PM, John Worden <[hidden email]> wrote:
> > I came to Squeak/Smalltalk and started having a play. There is something addictive about it but at the same time there are things like the speed issue above that don't make it "easy" for the learner. As an exercise I started to convert the excellent Cincom VW Tutorial to work in Squeak and at the same time I was converting it into Python. End result is that I had less difficulty getting it to work in Python than simply converting to Squeak. I wasn't expecting that. (For interest the other big problem I had, in addition to the speed one, was with the CrLf handling) > > I am not trying to compare one language to another. Neither is it a judgement call on whats right or wrong all have their fit I'm sure. My question is whether people feel Squeak really is suitable for someone who just enjoys scripting simple programs? I can see the value in it from an educational perspective but for someone like me (who to be honest doesn't even want to worry about what things like UTF8 Support are all about) is it a good choice? Squeak (and Smalltalk in general) is unusual as a dynamic language in that it doesn't come from a tradition of scripting. A lot of effort goes into making the Smalltalk world complete and less work goes into integrating with the outside world. That doesn't mean you can't do scripting in Squeak, but you may not find many people who've gone down that path. If I wanted to do a lot of scripting in a Smalltalk, I'd look at GNU Smalltalk. When I downloaded the source to build the book Squeak by Example, it was interesting to note that the build process was controlled by a GNU Smalltalk script (and that script was originally written in Ruby). The reason that is interesting is some experts (while writing a book on Squeak) chose a different Smalltalk to do their scripting. No value judgment, just an observation. That said, I've used Squeak for scripting and had a lot of fun doing it. Here is a message from the archive with more info on the experience: http://aspn.activestate.com/ASPN/Mail/Message/squeak-list/3456510 Of course, if you already know how to code in Python, and you are doing something like file and text processing, Squeak may come up short. Or, you may get addicted to Smalltalk and it will ruin you for other languages/environments. As Andy Bower said, "Smalltalk is dangerous. It is a drug. My advice to you would be don't try it." _______________________________________________ Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
Free forum by Nabble | Edit this page |