BMPReadWriterPlugin , do we really need it?
Locked
BMPReadWriterPlugin , do we really need it?
 
|
Hi, i just stumbled over it, and i thought that today, we don't really need such kind of cruft. It is just a two methods, and there is nothing essential, in it. And i think that .bmp image format is really crappy format, which no one using today, and given that we got Cog, it could run just a bit slower, if implemented in image w/o primitives. -- Best regards, Igor Stasenko AKA sig. |
Re: BMPReadWriterPlugin , do we really need it?
|
|
We should keep in mind that not everyone can use Cogit. On Dec 21, 2010, at 2:33 PM, Igor Stasenko <[hidden email]> wrote: > > Hi, > > i just stumbled over it, and i thought that today, we don't really > need such kind of cruft. > It is just a two methods, and there is nothing essential, in it. > > And i think that .bmp image format is really crappy format, which no > one using today, > and given that we got Cog, it could run just a bit slower, if > implemented in image w/o primitives. > > -- > Best regards, > Igor Stasenko AKA sig. |
Re: BMPReadWriterPlugin , do we really need it?
|
|
On 22 December 2010 00:08, Casey Ransberger <[hidden email]> wrote: > > We should keep in mind that not everyone can use Cogit. > so, does that sounds like: yes, throw it away from Cog VM build? ;) no, but serious, even if they can't/don't using Cog, they should stop using old, odd .bmp image format. And at last resort, people could always use old dusty VMs in their old dusty image(s), where .bmp(s) could be read there with lighting speed :) > On Dec 21, 2010, at 2:33 PM, Igor Stasenko <[hidden email]> wrote: > >> >> Hi, >> >> i just stumbled over it, and i thought that today, we don't really >> need such kind of cruft. >> It is just a two methods, and there is nothing essential, in it. >> >> And i think that .bmp image format is really crappy format, which no >> one using today, >> and given that we got Cog, it could run just a bit slower, if >> implemented in image w/o primitives. >> >> -- >> Best regards, >> Igor Stasenko AKA sig. > -- Best regards, Igor Stasenko AKA sig. |
Re: BMPReadWriterPlugin , do we really need it?
|
|
In reply to this post by Igor Stasenko
On 12/21/2010 2:33 PM, Igor Stasenko wrote: > i just stumbled over it, and i thought that today, we don't really > need such kind of cruft. This ain't cruft. This is a 10x performance boost (even over Cog). > It is just a two methods, and there is nothing essential, in it. The plugin is absolutely essential for high-performance reading of standard 24bpp BMP files. > And i think that .bmp image format is really crappy format, which no > one using today, Very funny. Spoken like a true Macvocate. Outside of academics PCs still play a pretty important role, and on Windows, BMP files are still the standard. > and given that we got Cog, it could run just a bit slower, if > implemented in image w/o primitives. Right. "Just a bit". 10x. Cheers, - Andreas |
Re: BMPReadWriterPlugin , do we really need it?
|
|
The only issue with BMPReadWriterPlugin was that for some reason the primitives weren't used. Probably an oversight on my behalf when I did the last Teleplace/Squeak sync. Fixed now. Benchmarks: 1600x1200 24bpp image [Form fromFileNamed: 'benchmark.bmp'] timeToRun. Interpreter read: 1684 msecs Cog read: 1158 msecs Primitive read: 100 msecs [BMPReadWriter putForm: f onFileNamed: 'benchmark.bmp'] timeToRun. Interpreter write: 693 msecs Cog write: 434 msecs Primitive write: 32 msecs So much for "just a bit" in speed. It's even more than I remembered[*]. [*] In particular considering that [Form extent: 1600@1200 depth: 32] timeToRun => 80 msecs. In other words the "real" performance difference is rather more along the lines of 50x in the actual code. Cheers, - Andreas On 12/21/2010 7:41 PM, Andreas Raab wrote: > > On 12/21/2010 2:33 PM, Igor Stasenko wrote: >> i just stumbled over it, and i thought that today, we don't really >> need such kind of cruft. > > This ain't cruft. This is a 10x performance boost (even over Cog). > >> It is just a two methods, and there is nothing essential, in it. > > The plugin is absolutely essential for high-performance reading of > standard 24bpp BMP files. > >> And i think that .bmp image format is really crappy format, which no >> one using today, > > Very funny. Spoken like a true Macvocate. Outside of academics PCs still > play a pretty important role, and on Windows, BMP files are still the > standard. > >> and given that we got Cog, it could run just a bit slower, if >> implemented in image w/o primitives. > > Right. "Just a bit". 10x. > > Cheers, > - Andreas > |
Re: BMPReadWriterPlugin , do we really need it?
|
|
In reply to this post by Andreas.Raab
On 22 December 2010 04:41, Andreas Raab <[hidden email]> wrote: > > On 12/21/2010 2:33 PM, Igor Stasenko wrote: >> >> i just stumbled over it, and i thought that today, we don't really >> need such kind of cruft. > > This ain't cruft. This is a 10x performance boost (even over Cog). > >> It is just a two methods, and there is nothing essential, in it. > > The plugin is absolutely essential for high-performance reading of standard > 24bpp BMP files. > >> And i think that .bmp image format is really crappy format, which no >> one using today, > > Very funny. Spoken like a true Macvocate. Outside of academics PCs still > play a pretty important role, and on Windows, BMP files are still the > standard. > even back in '95 i was looking for a way to get rid of using .bmps. And yeah... i am old windows user. :) >> and given that we got Cog, it could run just a bit slower, if >> implemented in image w/o primitives. > > Right. "Just a bit". 10x. > > Cheers, > - Andreas > -- Best regards, Igor Stasenko AKA sig. |
Re: BMPReadWriterPlugin , do we really need it?
|
|
In reply to this post by Andreas.Raab
On 22 December 2010 05:27, Andreas Raab <[hidden email]> wrote: > > The only issue with BMPReadWriterPlugin was that for some reason the > primitives weren't used. Probably an oversight on my behalf when I did the > last Teleplace/Squeak sync. Fixed now. > > Benchmarks: 1600x1200 24bpp image > > [Form fromFileNamed: 'benchmark.bmp'] timeToRun. > > Interpreter read: 1684 msecs > Cog read: 1158 msecs > Primitive read: 100 msecs > > > [BMPReadWriter putForm: f onFileNamed: 'benchmark.bmp'] timeToRun. > > Interpreter write: 693 msecs > Cog write: 434 msecs > Primitive write: 32 msecs > and since it uncompressed (because .bmp can't even compress the data) it takes 1600*1200*3 = 5760000 bytes on disk! Now try convert it to either PNG or JPEG and see the difference. One of the reasons why this format are so slow, because reading 10x times more data from hard disk takes 10x more time than reading 1x data and unpacking it. > So much for "just a bit" in speed. It's even more than I remembered[*]. > > [*] In particular considering that [Form extent: 1600@1200 depth: 32] > timeToRun => 80 msecs. In other words the "real" performance difference is > rather more along the lines of 50x in the actual code. > > Cheers, > - Andreas > > On 12/21/2010 7:41 PM, Andreas Raab wrote: >> >> On 12/21/2010 2:33 PM, Igor Stasenko wrote: >>> >>> i just stumbled over it, and i thought that today, we don't really >>> need such kind of cruft. >> >> This ain't cruft. This is a 10x performance boost (even over Cog). >> >>> It is just a two methods, and there is nothing essential, in it. >> >> The plugin is absolutely essential for high-performance reading of >> standard 24bpp BMP files. >> >>> And i think that .bmp image format is really crappy format, which no >>> one using today, >> >> Very funny. Spoken like a true Macvocate. Outside of academics PCs still >> play a pretty important role, and on Windows, BMP files are still the >> standard. >> >>> and given that we got Cog, it could run just a bit slower, if >>> implemented in image w/o primitives. >> >> Right. "Just a bit". 10x. >> >> Cheers, >> - Andreas >> > -- Best regards, Igor Stasenko AKA sig. |
Re: BMPReadWriterPlugin , do we really need it?
|
|
So igor may be this is just nostalgia. :) In any case your email was fun to read and I learned a lot of crunchy details. Stef PS: when I hear bashing mac I would not call you an mac fan :) On Dec 22, 2010, at 8:40 AM, Igor Stasenko wrote: > > On 22 December 2010 05:27, Andreas Raab <[hidden email]> wrote: >> >> The only issue with BMPReadWriterPlugin was that for some reason the >> primitives weren't used. Probably an oversight on my behalf when I did the >> last Teleplace/Squeak sync. Fixed now. >> >> Benchmarks: 1600x1200 24bpp image >> > > >> [Form fromFileNamed: 'benchmark.bmp'] timeToRun. >> >> Interpreter read: 1684 msecs >> Cog read: 1158 msecs >> Primitive read: 100 msecs >> >> >> [BMPReadWriter putForm: f onFileNamed: 'benchmark.bmp'] timeToRun. >> >> Interpreter write: 693 msecs >> Cog write: 434 msecs >> Primitive write: 32 msecs >> > > and since it uncompressed (because .bmp can't even compress the data) > it takes 1600*1200*3 = 5760000 bytes on disk! > Now try convert it to either PNG or JPEG and see the difference. > One of the reasons why this format are so slow, because reading 10x > times more data from hard disk > takes 10x more time than reading 1x data and unpacking it. > >> So much for "just a bit" in speed. It's even more than I remembered[*]. >> >> [*] In particular considering that [Form extent: 1600@1200 depth: 32] >> timeToRun => 80 msecs. In other words the "real" performance difference is >> rather more along the lines of 50x in the actual code. >> >> Cheers, >> - Andreas >> >> On 12/21/2010 7:41 PM, Andreas Raab wrote: >>> >>> On 12/21/2010 2:33 PM, Igor Stasenko wrote: >>>> >>>> i just stumbled over it, and i thought that today, we don't really >>>> need such kind of cruft. >>> >>> This ain't cruft. This is a 10x performance boost (even over Cog). >>> >>>> It is just a two methods, and there is nothing essential, in it. >>> >>> The plugin is absolutely essential for high-performance reading of >>> standard 24bpp BMP files. >>> >>>> And i think that .bmp image format is really crappy format, which no >>>> one using today, >>> >>> Very funny. Spoken like a true Macvocate. Outside of academics PCs still >>> play a pretty important role, and on Windows, BMP files are still the >>> standard. >>> >>>> and given that we got Cog, it could run just a bit slower, if >>>> implemented in image w/o primitives. >>> >>> Right. "Just a bit". 10x. >>> >>> Cheers, >>> - Andreas >>> >> > > > > -- > Best regards, > Igor Stasenko AKA sig. |
Re: BMPReadWriterPlugin , do we really need it?
|
|
In reply to this post by Igor Stasenko
On 12/21/2010 11:40 PM, Igor Stasenko wrote: > One of the reasons why this format are so slow, because reading 10x > times more data from hard disk > takes 10x more time than reading 1x data and unpacking it. Simply not true. Run the benchmarks. PNG and BMP are roughly equal; JPEG is quite a bit slower. Cheers, - Andreas |
Re: BMPReadWriterPlugin , do we really need it?
|
|
In reply to this post by stephane ducasse-2
On 22 December 2010 09:18, stephane ducasse <[hidden email]> wrote: > > So igor may be this is just nostalgia. :) > In any case your email was fun to read and I learned a lot of crunchy details. > > Stef > PS: when I hear bashing mac I would not call you an mac fan :) > yes, partly because i not very productive with mac os, since it is new to me. but i am already see things, which i don't like. And its not because i am a jerky antagonist, who hates everything new, but because i seen better things :) -- Best regards, Igor Stasenko AKA sig. |
Re: BMPReadWriterPlugin , do we really need it?
|
|
In reply to this post by Andreas.Raab
On 22 December 2010 09:30, Andreas Raab <[hidden email]> wrote: > > On 12/21/2010 11:40 PM, Igor Stasenko wrote: >> >> One of the reasons why this format are so slow, because reading 10x >> times more data from hard disk >> takes 10x more time than reading 1x data and unpacking it. > > Simply not true. Run the benchmarks. PNG and BMP are roughly equal; JPEG is > quite a bit slower. So, since PNG and BMP performance are on par, then i would make .bmp reading 10x times slower, for purpose of forcing users avoid using this crappy format :) But lets end this discussion. If you think this stuff is still relevant, so be it. > > Cheers, > - Andreas > -- Best regards, Igor Stasenko AKA sig. |
|
|
In reply to this post by Andreas.Raab
This would depend on *if* your JPEG test is using the JPEG primitives, or is it using the software jpeg logic (with slight primitive optimization). On 2010-12-22, at 12:30 AM, Andreas Raab wrote: > On 12/21/2010 11:40 PM, Igor Stasenko wrote: >> One of the reasons why this format are so slow, because reading 10x >> times more data from hard disk >> takes 10x more time than reading 1x data and unpacking it. > > Simply not true. Run the benchmarks. PNG and BMP are roughly equal; JPEG is quite a bit slower. > > Cheers, > - Andreas -- =========================================================================== John M. McIntosh <[hidden email]> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com =========================================================================== |
Re: BMPReadWriterPlugin , do we really need it?
|
|
On 12/22/2010 12:49 AM, John M McIntosh wrote: > This would depend on *if* your JPEG test is using the JPEG primitives, or is it using the software jpeg logic (with slight primitive optimization). The comparison is with libjpeg and libpng. If you don't use those you loose big time. Cheers, - Andreas > On 2010-12-22, at 12:30 AM, Andreas Raab wrote: > >> On 12/21/2010 11:40 PM, Igor Stasenko wrote: >>> One of the reasons why this format are so slow, because reading 10x >>> times more data from hard disk >>> takes 10x more time than reading 1x data and unpacking it. >> >> Simply not true. Run the benchmarks. PNG and BMP are roughly equal; JPEG is quite a bit slower. >> >> Cheers, >> - Andreas > > -- > =========================================================================== > John M. McIntosh<[hidden email]> Twitter: squeaker68882 > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > =========================================================================== > > > > > |
Re: BMPReadWriterPlugin , do we really need it?
|
|
In reply to this post by Andreas.Raab
On Tue, Dec 21, 2010 at 8:27 PM, Andreas Raab <[hidden email]> wrote:
Interesting. I just profiled this (*) with the VM interpreter and the culprit is the file i/o implementation. On Mac OS X fully 70% of entire execution time is in the lseek and write system calls. That explains why the speedup with Cog is so modest. Cog is unable to speedup the file writes.
(*) I'm actually profiling the entirety of (BMPReadWriter on: (FileStream fileNamed: 'benchmark.bmp') binary)
nextPutImage: (Form extent: 1600@1200 depth: 32); close
Mac OS X 10.6.5 2.66GHz Core i7 Cog [(BMPReadWriter on: (FileStream fileNamed: 'benchmark.bmp') binary) nextPutImage: (Form extent: 1600@1200 depth: 32);
close] timeToRun 8701 (e.g. I see numbers in the 8600 to 9500 range)
|
«
Return to Squeak VM
|
1 view|%1 views
| Free forum by Nabble | Edit this page |