[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-kimageshop
Subject: Re: koffice/krita/benchmarks
From: Dmitry Kazakov <dimula73 () gmail ! com>
Date: 2010-01-25 10:00:11
Message-ID: ae32c1ef1001250200s749cf456kaf8bcd2973d92101 () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Mon, Jan 25, 2010 at 12:15 PM, Boudewijn Rempt wrote:
> On Mon, 25 Jan 2010, Dmitry Kazakov wrote:
>
> > Hah.. These results are quite unobjective =) You were reading and writing
> > empty pixels, that is a special case in both managers. And doesn't show
> > actual read/write speed. Though shows a different thing...
>
> Does any tile engine actually check whether the contents of a block of
> pixels is all the same as the default pixel? I can't find any code in the
> writeBytes codepath that does that, so I am fairly sure that we are filling
> tiles
> with pixels in the benchmark.
>
Yeah, no checking, it just makes me think too much when i'm trying to
calculate the size of manually created arrays =)
You can use filled arrays instead of hakonepa of course. But you need to
split the time of allocation and reading/writing - that's the point.
> So I think the writeBytes benchmark tests allocating tiles and filling the
> tiles
> with data,
Yes. And as no transaction was created, there is no memento'ing
> the readBytes benchmark tests reading the default tile,
Exactly! Do you know any real-life benefit of reading default tile? ;) I'd
better know actual read-time instead.
the readWrite benchmark tests first writing real data, then reading real
> data.
>
This result is the nearest to the real-world one, but it is dirtied by
1/100th of allocation time and doesn't show separate read and write times.
>
> > Writing of pixels to the empty dm shows in both engines:
> > 1) speed of allocation of a new tile
> > 2) speed of filling this tile with data
> >
> > Reading from the empty dm shows different things for both engines
> (remember,
> > that tiles3 still has "extents"-bug)
>
> Do you have any prognosis for a fix for that?
>
After walkers finished and synchronization between image<->ui done. And i
promised Edward to fix some bug in tiles3 after walkers, iirc...
>
> > For tiles/
> > 1) speed of reading of the default tile, that is preallocated inside dm
> >
> > For tiles3/
> > 1) speed of allocation of a new tile
> > 2) speed of reading this tile
> > This should be fixed of course, but i'm still trying to find time for
> that.
>
> It's sort of a blocker for 2.2, I think.
>
I don't think so. If it don't cause more severe bugs... Nevertheless, it's
not that much time to fix.
>
> > I thing "nominations" should be the following:
> >
> > 1) Reading:
> > load some image (e.g. hakonepa or smth bigger), and read it
> > 2) Writing:
> > write hakonepa to dm
> > 3) Clearing:
> > clear(someColor) - this should be much faster in new engine
> > 4) Reading *empty* dm - reveals my bug
> > 5) Writing *empty* dm. If we subtract 2nd number form this, we'll get
> pure
> > time of allocation of new tiles. This should be very interesting result.
> >
> > 6) Btw, we should test Memento mechanism:
> > o write-getMemento-repeat
> > o read-write-read-getMemento-repeat
>
> Yes, the memento performance should be benchmarked as well.
> >
> > --
> > Dmitry Kazakov
> >
>
> _______________________________________________
> kimageshop mailing list
> kimageshop@kde.org
> https://mail.kde.org/mailman/listinfo/kimageshop
>
--
Dmitry Kazakov
[Attachment #5 (text/html)]
<div class="gmail_quote">On Mon, Jan 25, 2010 at 12:15 PM, Boudewijn Rempt \
wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px \
#ccc solid;padding-left:1ex;"><div class="im">On Mon, 25 Jan 2010, Dmitry Kazakov \
wrote:<br>
<br>
> Hah.. These results are quite unobjective =) You were reading and writing<br>
> empty pixels, that is a special case in both managers. And doesn't show<br>
> actual read/write speed. Though shows a different thing...<br>
<br>
</div>Does any tile engine actually check whether the contents of a block of<br>
pixels is all the same as the default pixel? I can't find any code in the<br>
writeBytes codepath that does that, so I am fairly sure that we are filling tiles<br>
with pixels in the benchmark.<br></blockquote><div><br></div><div>Yeah, no checking, \
it just makes me think too much when i'm trying to calculate the size of manually \
created arrays =)</div><div>You can use filled arrays instead of hakonepa of course. \
But you need to split the time of allocation and reading/writing - that's the \
point.</div> <div> </div><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex;">So I think the writeBytes \
benchmark tests allocating tiles and filling the tiles<br> with data, \
</blockquote><div>Yes. And as no transaction was created, there is no \
memento'ing</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex;">the readBytes benchmark tests \
reading the default tile,</blockquote> <div>Exactly! Do you know any real-life \
benefit of reading default tile? ;) I'd better know actual read-time \
instead.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex;"> the readWrite benchmark tests \
first writing real data, then reading real data.<br></blockquote><div>This result is \
the nearest to the real-world one, but it is dirtied by 1/100th of allocation time \
and doesn't show separate read and write times.</div> <div> </div><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex;"> <div class="im"><br>
> Writing of pixels to the empty dm shows in both engines:<br>
> 1) speed of allocation of a new tile<br>
> 2) speed of filling this tile with data<br>
><br>
> Reading from the empty dm shows different things for both engines (remember,<br>
> that tiles3 still has "extents"-bug)<br>
<br>
</div>Do you have any prognosis for a fix for \
that?<br></blockquote><div><br></div><div>After walkers finished and synchronization \
between image<->ui done. And i promised Edward to fix some bug in tiles3 after \
walkers, iirc...</div> <div> </div><blockquote class="gmail_quote" style="margin:0 0 \
0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <div class="im"><br>
> For tiles/<br>
> 1) speed of reading of the default tile, that is preallocated inside dm<br>
><br>
> For tiles3/<br>
> 1) speed of allocation of a new tile<br>
> 2) speed of reading this tile<br>
> This should be fixed of course, but i'm still trying to find time for \
that.<br> <br>
</div>It's sort of a blocker for 2.2, I \
think.<br></blockquote><div><br></div><div>I don't think so. If it don't \
cause more severe bugs... Nevertheless, it's not that much time to \
fix.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
> I thing "nominations" should be the following:<br>
><br>
> 1) Reading:<br>
> load some image (e.g. hakonepa or smth bigger), and read it<br>
> 2) Writing:<br>
> write hakonepa to dm<br>
> 3) Clearing:<br>
> clear(someColor) - this should be much faster in new engine<br>
> 4) Reading *empty* dm - reveals my bug<br>
> 5) Writing *empty* dm. If we subtract 2nd number form this, we'll get \
pure<br> > time of allocation of new tiles. This should be very interesting \
result.<br> ><br>
> 6) Btw, we should test Memento mechanism:<br>
> o write-getMemento-repeat<br>
> o read-write-read-getMemento-repeat<br>
<br>
</div>Yes, the memento performance should be benchmarked as well.<br>
><br>
> --<br>
> Dmitry Kazakov<br>
><br>
<br>
_______________________________________________<br>
kimageshop mailing list<br>
<a href="mailto:kimageshop@kde.org">kimageshop@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/kimageshop" \
target="_blank">https://mail.kde.org/mailman/listinfo/kimageshop</a><br> \
</blockquote></div><br><br clear="all"><br>-- <br>Dmitry Kazakov<br>
_______________________________________________
kimageshop mailing list
kimageshop@kde.org
https://mail.kde.org/mailman/listinfo/kimageshop
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic