WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
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-
Details
Formatted Diff
Diff
View All
Add attachment
proposed patch, testcase, etc.
Xingnan Wang
Comment 1
2012-02-27 20:30:44 PST
Created
attachment 129177
[details]
Patch
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.
Top of Page
Format For Printing
XML
Clone This Bug