[Vm-dev] BMPReadWriterPlugin , do we really need it?

[Eliot Miranda]

On Tue, Dec 21, 2010 at 8:27 PM, Andreas Raab <andreas.raab at gmx.de> 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
>
> So much for "just a bit" in speed. It's even more than I remembered[*].
>
> [*] In particular considering that [Form extent: 1600 at 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.
>

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 at 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 at 1200 depth: 32);
close] timeToRun 8701  (e.g. I see numbers in the 8600 to 9500 range)



> 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
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20101223/f71c9d1d/attachment.htm