For some strange reason our latest version of VLC OSX more than doubles the CPU usage of mad_frame_decode, specifically the imdct36 routine it would seem. It is an OS X problem only and very annoying. Decoding mp3 now requires 28% CPU usage on my G4/400 (used to be 12%).
libmad library version changes have been ruled out as the cause of this. Our mp3 decoder module didn't change either, but the demux module did change. We suspect it might be something like an alignment issue, but we can't seem to track it down..
Could you give some advice as to what might be the cause of this sudden increase in CPU usage, and how me may check some of our input for correctness?
DJ
--- Universiteit Twente Derk-Jan Hartman (d.hartman at student.utwente dot nl) http://home.student.utwente.nl/d.hartman
On Feb 14, 2004, at 7:30 AM, Derk-Jan Hartman wrote:
For some strange reason our latest version of VLC OSX more than doubles the CPU usage of mad_frame_decode, specifically the imdct36 routine it would seem. It is an OS X problem only and very annoying. Decoding mp3 now requires 28% CPU usage on my G4/400 (used to be 12%).
libmad library version changes have been ruled out as the cause of this. Our mp3 decoder module didn't change either, but the demux module did change. We suspect it might be something like an alignment issue, but we can't seem to track it down..
Could you give some advice as to what might be the cause of this sudden increase in CPU usage, and how me may check some of our input for correctness?
I don't think alignment should be an issue since nothing in imdct36() depends on the alignment of the bitstream.
The only possibility I can see affecting the performance of imdct36() might be a possible change in compilation directives. The preprocessor symbols FPM_*, OPT_SPEED, and OPT_ACCURACY can all drastically affect performance, as can the selection of compiler optimization flags. You might check to make sure these have not changed.
On 15 feb 2004, at 02:56, Rob Leslie wrote:
On Feb 14, 2004, at 7:30 AM, Derk-Jan Hartman wrote:
For some strange reason our latest version of VLC OSX more than doubles the CPU usage of mad_frame_decode, specifically the imdct36 routine it would seem. It is an OS X problem only and very annoying. Decoding mp3 now requires 28% CPU usage on my G4/400 (used to be 12%).
libmad library version changes have been ruled out as the cause of this. Our mp3 decoder module didn't change either, but the demux module did change. We suspect it might be something like an alignment issue, but we can't seem to track it down..
Could you give some advice as to what might be the cause of this sudden increase in CPU usage, and how me may check some of our input for correctness?
I don't think alignment should be an issue since nothing in imdct36() depends on the alignment of the bitstream.
The only possibility I can see affecting the performance of imdct36() might be a possible change in compilation directives. The preprocessor symbols FPM_*, OPT_SPEED, and OPT_ACCURACY can all drastically affect performance, as can the selection of compiler optimization flags. You might check to make sure these have not changed.
i configured mad to be as fast as possible and still it's twice as intensive as in the older release. I'm working with profiling data here, so it's a bit hard to detect the problem. However... Though imdct36 is taking the most time by far, I noticed that the difference is within III_decode() III_decode takes almost the same CPU time in both versions. however then the differences start.
III_imdct_l takes 2.7% in old version and 7.8% in the new version. That imdct36() is called more often because of this is logical of course. So the problem is probably somewhere within III_decode() and causing III_imdct_l to be called more often than before... Any new ideas after this information?
DJ
--- Universiteit Twente Derk-Jan Hartman (d.hartman at student.utwente dot nl) http://home.student.utwente.nl/d.hartman
On Feb 18, 2004, at 3:23 AM, Derk-Jan Hartman wrote:
i configured mad to be as fast as possible and still it's twice as intensive as in the older release. I'm working with profiling data here, so it's a bit hard to detect the problem. However... Though imdct36 is taking the most time by far, I noticed that the difference is within III_decode() III_decode takes almost the same CPU time in both versions. however then the differences start.
III_imdct_l takes 2.7% in old version and 7.8% in the new version. That imdct36() is called more often because of this is logical of course. So the problem is probably somewhere within III_decode() and causing III_imdct_l to be called more often than before... Any new ideas after this information?
Are you decoding the same bitstream for comparison?
The number of times III_imdct_l() is called depends on the signal being decoded. It may not be called at all in the case of short blocks, or it may be called only a few times, or several. It varies with the complexity of the signal.
If you are using the same bitstream, is the decoded output identical?
-
Derk-Jan Hartman -
Rob Leslie