Re: OpenExr 2.3 - slower write speeds for Uncompressed and Zip1

--===============6338066308655991485==
Content-Type: multipart/alternative; boundary="000000000000dd1eb005872f968e"

--000000000000dd1eb005872f968e
Content-Type: text/plain; charset="UTF-8"

Hi,

I believe I found the issue, but I still need to make the proper
measurement. After a few measurements I found that the time this function
spent most was two load operations, where it loads the read and write
pointers back into a registers. This was very suspicious as the function
should not use all that many registers, and shouldn't need to cycle them
out back to their address. The function accepts references to the read and
write pointers which is seemingly throwing the compiler off. By capturing
them into local variable as just straight pointers, and writing them back
before return seems to eliminate the problem. But I need to make more
measurement before I submit a patch.

On Tue, 23 Apr 2019 at 10:26, Kevin Wheatley <[email protected]>
wrote:

> another data point.
>
> When I first experimented with adding DWA to Nuke using OpenEXR 2.2.0 I
> had to patch the configure so I could enable f16c instructions for gcc
> 4.1.2, after doing so vtune pointed to the copyFromFrameBuffer function
> when going from half to float for ~30+% of the CPU when reading files from
> local SSD. (Aside, there were a number of other namespace related fixes
> that were needed too, all of these are in the latest OpenEXR versions). I
> came to the conclusion that to make the performance any better it would
> need a f16c based half to float conversion function rather than going via
> the LUT, at least for those CPUs supporting those instructions. I also have
> some notes about testing memory mapped reading, but no conclusions.
>
> This was not the case when f16c were disabled as other functions appeared
> higher in the profile - the total performance was lower without f16c (no
> surprise), it was only because the other functions got reduced by the f16c
> that bubbled copyFromFrameBuffer to the top.
>
> I didn't try RLE compression.
> Kevin
>

--000000000000dd1eb005872f968e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi,</div><div><br></div><div>I believe I found the is=
sue, but I still need to make the proper measurement. After a few measureme=
nts I found that the time this function spent most was two load operations,=
 where it loads the read and write pointers back into a registers. This was=
 very suspicious as the function should not use all that many registers, an=
d shouldn&#39;t need to cycle them out back to their address. The function =
accepts references to the read and write pointers which is seemingly throwi=
ng the compiler off. By capturing them into local variable as just straight=
 pointers, and writing them back before return seems to eliminate the probl=
em. But I need to make more measurement before I submit a patch.<br></div><=
/div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">O=
n Tue, 23 Apr 2019 at 10:26, Kevin Wheatley &lt;<a href=3D"mailto:kevin.j.w=
[email protected]">[email protected]</a>&gt; wrote:<br></div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:=
1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>another =
data point.</div><div><br></div><div>When I first experimented with adding =
DWA to Nuke using OpenEXR 2.2.0 I had to patch the configure so I could ena=
ble f16c instructions for gcc 4.1.2, after doing so vtune pointed to the co=
pyFromFrameBuffer function when going from half to float for ~30+% of the C=
PU when reading files from local SSD. (Aside, there were a number of other =
namespace related fixes that were needed too, all of these are in the lates=
t OpenEXR versions). I came to the conclusion that to make the performance =
any better it would need a f16c based half to float conversion function rat=
her than going via the LUT, at least for those CPUs supporting those instru=
ctions. I also have some notes about testing memory mapped reading, but no =
conclusions.<br></div><div><br></div><div>This was not the case when f16c w=
ere disabled as other functions appeared higher in the profile - the total =
performance was lower without f16c (no surprise), it was only because the o=
ther functions got reduced by the f16c that bubbled copyFromFrameBuffer to =
the top.</div><div><br></div><div>I didn&#39;t try RLE compression.<br></di=
v><div></div><div>Kevin<br></div></div>
</blockquote></div>

--000000000000dd1eb005872f968e--


--===============6338066308655991485==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Openexr-devel mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/openexr-devel

--===============6338066308655991485==--