I unfortunately can't get VTune to work reliably on LAME.
If someone wants to point me toward any other math-intensive
inner loops I will be glad to optimize those as well.
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Has anybody tried optimizing filter banks?
rdgs
soyeb
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
On 15-Oct-99 Richard A. Smith wrote:
> On Fri, 15 Oct 1999 10:59:39 +0100 (WEST), Patrick De Smet wrote:
>>Anyway, I got this idea from a recent book discussing all sorts of optims,
>>and how (good) recent compilers work, I can look up the ref if you want
>>it;
>
> Yes please send me the ref off
> From: "Acy Stapp" <[EMAIL PROTECTED]>
>
> I unfortunately can't get VTune to work reliably on LAME.
> If someone wants to point me toward any other math-intensive
> inner loops I will be glad to optimize those as well.
The other big one is the FFT code; always shows up near the top of profiles.
On Fri, 3 Dec 1999, Mathew Hendry wrote:
> > From: "Acy Stapp" <[EMAIL PROTECTED]>
> >
> > I unfortunately can't get VTune to work reliably on LAME.
> > If someone wants to point me toward any other math-intensive
> > inner loops I will be glad to optimize those as well.
>
> The other big one i
> Has anybody tried optimizing filter banks?
What do you mean exactly?
Ciao,
Segher
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
:: Has anybody tried optimizing filter banks?
::
Speed, Quality, Code size?
--
Mit freundlichen Grüßen
Frank Klemm
eMail | [EMAIL PROTECTED] home: [EMAIL PROTECTED]
phone | +49 (3641) 64-2721home: +49 (3641) 390545
sMail | R.-Breitscheid-Str. 43, 07747 Jena, Germany
--
MP3 ENCODER
i mean in terms of speed like using faster algo like Lee's IDCT for faster
implementation.
rgds
soyeb
Segher Boessenkool wrote:
>
> > Has anybody tried optimizing filter banks?
>
> What do you mean exactly?
>
> Ciao,
>
> Segher
> --
> MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/
> i mean in terms of speed like using faster algo like Lee's IDCT for faster
> implementation.
> rgds
> soyeb
Ok. Yes, been there, done that. The 32 point dct II, as well as the 18 point
dct IV. Both with a Lee -like algorithm. Works like a charm :-)
The slowest part is the polyphase windowing, a
You can use NamLing's algorithm for that instead og 512 mul for each iteration
it will take 256 + 32 mul, i am not able to figure out how to implement
recursive formulla.
The Namling's paper is available at
"Two polyphase filter architecture for MPEG audio",Namling,Shih, IEEE trans.
speech and au
>
> You can use NamLing's algorithm for that instead og 512 mul for each iteration
> it will take 256 + 32 mul, i am not able to figure out how to implement
> recursive formulla.
> The Namling's paper is available at
> "Two polyphase filter architecture for MPEG audio",Namling,Shih, IEEE trans.
>
Has anybody tried NamLing's recursive formulla for subband filter windowing.
rgds
soyeb
Segher Boessenkool wrote:
>
> > i mean in terms of speed like using faster algo like Lee's IDCT for faster
> > implementation.
> > rgds
> > soyeb
>
> Ok. Yes, been there, done that. The 32 point dct II, as w
- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, October 16, 1999 10:19 AM
Subject: [MP3 ENCODER] Optimization Techniques
> On 15-Oct-99 Richard A. Smith wrote:
> > On Fri, 15 Oct 1999 10:59:39 +0100 (WEST), Patrick De Smet wro
On Sat, 16 Oct 1999 22:54:32 +0100, Mathew Hendry wrote:
>With gcc, using array notation is usually faster (particularly, I found,
>when the dataset exceeds the level 2 cache size - couldn't figure out
>why...)
I don't know a whole lot about x86 assembly and the pentium arch but
perhaps there is
On Mon, 18 Oct 1999 00:58:28 -0500, Richard A. Smith wrote:
>On another note My latest Linux Journal has an article about
>performance of programs based on compilers. pgcc appears to help
>with speed. Anyone tried to get lame to compile under pgcc?
I've been compiling LAME with pgcc the whole
> On another note My latest Linux Journal has an article about
> performance of programs based on compilers. pgcc appears to help
> with speed. Anyone tried to get lame to compile under pgcc?
pgcc should be avoided at all costs. It seems not to care about generating
bogus code so long as the
> "R" == Richard A Smith <[EMAIL PROTECTED]> writes:
R> On another note My latest Linux Journal has an article about
R> performance of programs based on compilers. pgcc appears to
R> help with speed. Anyone tried to get lame to compile under
R> pgcc?
It's true PGCC(2.91.57)
> From: Richard A. Smith [mailto:[EMAIL PROTECTED]]
>
> On Sat, 16 Oct 1999 22:54:32 +0100, Mathew Hendry wrote:
>
> >With gcc, using array notation is usually faster
> (particularly, I found,
> >when the dataset exceeds the level 2 cache size - couldn't figure out
> >why...)
>
> Perhaps we sh
On Sat, 16 Oct 1999, Mathew Hendry wrote:
> > As a suggestion keep the subject relevant so that people can filter if
> they
> > want.
Sorry, copied from answer in other thread (toolame1d):
http://www.oreilly.com/catalog/hpc2/toc.html
> Quite a good page:
>
> http://www.ontek.com/mikey/optimi
On Mon, 18 Oct 1999 12:16:32 +0100, Mathew Hendry wrote:
>> From: Richard A. Smith [mailto:[EMAIL PROTECTED]]
>>
>> Perhaps we should examine the compiler assembly output of the 2 test
>> cases.
>/* "array" version */
>L19:
> addl (%ecx,%edx,4),%eax
> subl $1,%edx
> jnc L19
>L
On Mon, 18 Oct 1999 12:16:32 +0100, Mathew Hendry wrote:
>/* "array" version */
>
>int
>sum_array_ar(int *array, long len) {
> int sum = 0;
> long i;
> for (i = len; i--;)
>sum += array[i];
> return sum;
>}
I just noticed that you pass array into the function in pointer
notation but then
> From: Richard A. Smith [mailto:[EMAIL PROTECTED]]
>
> On Mon, 18 Oct 1999 12:16:32 +0100, Mathew Hendry wrote:
>
> >int
> >sum_array_ar(int *array, long len) {
>
> I just noticed that you pass array into the function in pointer
> notation but then use it as an array inside the funtion. I have
> From: Richard A. Smith [mailto:[EMAIL PROTECTED]]
>
> Well there's the answer. The pointer version has an extra addl
> instruction. Does this hold true for an array of floats as well?
Yes.
_sum_array_ar:
movl 4(%esp),%edx
fldz
movl 8(%esp),%eax
decl %eax
> Just another remark/suggestion, which could maybe be true for all other
> things relevant to (too)lame also;
> is anyone doing/considering documenting the code (outside the C-src);
> I also mean at several levels:
> 1) theoretical optimization stuff e.g. subband anal/resynth
> window is symmetri
On 18-Oct-99 Patrick De Smet wrote:
> is anyone doing/considering documenting the code (outside the C-src);
I did this for the MDCT code - should probably be updated. I had spent a lot of
time online, hoping that someone else had already written it.
I see documenting as a good idea - sort of
Hello Paul,
Monday, October 18, 1999, 8:02:31 AM, you wrote:
>>On another note My latest Linux Journal has an article about
>>performance of programs based on compilers. pgcc appears to help
>>with speed. Anyone tried to get lame to compile under pgcc?
PH> I've been compiling LAME with pgcc t
26 matches
Mail list logo
