Patrick De Smet wrote:
> I was also looking into this kind of thing to change the lame code all
> over the place (i.e. inside the subbandfiltering).
> (Part of) Reason for speed up I believe is you can save/replace the 'i'
> "cmp value + bne/beq" assembler with only "bne/beq" (branch equal or not).
> Never checked actual gcc output assembler and speed myself; could/should
> be done for (too)lame ? Just another thing I'll add to my optim/sb-filter
> list I guess :( ;)
>
> regards,
> Patrick.
Yeah, I was noticiing some places with things like:
for (i=0;i<248;i++) {
if (i<64) {
(do x)
else (i<64) {
(do y)
and was wondering how much:
for (i=0;i<64;i++) {
do x
for (i=64;i<248;i++) {
do y
would speed things up, and whether the compiler would
be clever enough to catch it. (It's easier to read the
first way, but introduces 248 unneeded comparisons).
I'll look at the new cleaned up code now.
>
> --
> MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
--
Bill Eldridge
Radio Free Asia
[EMAIL PROTECTED]
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
