RESOLVED WONTFIX 79739
Use IPP malloc for AudioArray
https://bugs.webkit.org/show_bug.cgi?id=79739
Summary Use IPP malloc for AudioArray
Xingnan Wang
Reported 2012-02-27 20:23:24 PST
IPP library provides the ippmalloc which can malloc memory aligned with 32-byte. As AudioArray needs 16-byte alignment we can use ippmalloc instead.
Attachments
Patch (4.20 KB, patch)
2012-02-27 20:30 PST, Xingnan Wang
jchaffraix: review-
Xingnan Wang
Comment 1 2012-02-27 20:30:44 PST
Xingnan Wang
Comment 2 2012-02-27 20:31:41 PST
(In reply to comment #1) > Created an attachment (id=129177) [details] > Patch Uploaded the patch, thanks.
Chris Rogers
Comment 3 2012-02-27 20:32:00 PST
Will 32-byte alignment get us any advantage over the 16-byte alignment?
Xingnan Wang
Comment 4 2012-02-27 20:42:13 PST
(In reply to comment #3) > Will 32-byte alignment get us any advantage over the 16-byte alignment? I think 32-byte and 16-byte alignment are not too much different here, I have to use it because the IPP only provides 32-byte aligned ippmalloc function. The advantage we can get is the aligned memory is more easily allocated than original way.
Chris Rogers
Comment 5 2012-02-28 18:37:51 PST
(In reply to comment #4) > (In reply to comment #3) > > Will 32-byte alignment get us any advantage over the 16-byte alignment? > > I think 32-byte and 16-byte alignment are not too much different here, I have to use it because the IPP only provides 32-byte aligned ippmalloc function. The advantage we can get is the aligned memory is more easily allocated than original way. I'm not sure what you mean by "more easily allocated". I understand that the run-time code path in the IPP case would be slightly simpler in AudioArray.h, but is it actually a measurable performance win? The disadvantage of having this special-casing is that the code is somewhat harder to read with this patch. And this particular file is already somewhat tweaky even as it is right now, so it would be great to avoid adding additional complexity (harder to read through the code) unless there's a pretty good win.
Julien Chaffraix
Comment 6 2012-04-19 15:59:55 PDT
Comment on attachment 129177 [details] Patch I agree with Chris here. If the switch leads to performance benefits then we should consider this change but in the absence of hard evidence or more substancial explanations, this is a maintenance burden on the project with little benefits.
Note You need to log in before you can comment on or make changes to this bug.