The codebase sets up ogg_int32_t, etc, but then uses long directly in several structures. Unfortunately for me longs are 64 bits on my platform, not 32, and I end up getting hammered by unnecessary software math routine calls. Should I be able to just search/replace 'long' with 'ogg_int32_t' in the code or would that cause more problems than it fixes? -Dave --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'vorbis-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
On Thursday 22 May 2003 09:11, David Etherton wrote:> The codebase sets up ogg_int32_t, etc, but then uses long directly in > several structures. Unfortunately for me longs are 64 bits on my platform, > not 32, and I end up getting hammered by unnecessary software math routine > calls. > > Should I be able to just search/replace 'long' with 'ogg_int32_t' in the > code or would that cause more problems than it fixes?Yes, that should be fine (watch for the unsigned longs, though - there aren't many). The ogg and vorbis libraries are all pretty careful to specifically use ogg_int64_t where they _need_ more than 32 bit integers. I doubt it's something we want to accept into mainline-cvs, but perhaps we could set up a branch for weird-ps2-optimisations, if other people are going to find this useful? long being software-emulated is very weird, I dobut many other platforms do that - and since many of the longs are in the public API, we couldn't change them for the normal version anyway. Mike --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'vorbis-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
Looking into it a little more, it looks like the codebooks are the cause -- they
have lots of longs as internal structures and codebook.c and sharedbook.c both
trigger several "software math library call" warning messages.
Looking in books/* header files, I see that most of the numbers in the static
tables aren't even eight bits, much less 32 or 64. Perhaps we could clean
up the codebook code to use narrower types like ogg_int32_t? Seems like that
might save some memory too unless I'm totally misunderstanding things.
Rolling back my "long" changes, mdct_backward is 11% of my cpu time,
vorbis_book_decodevv_add is 3%, and __divdi3 is 3%.
Applying the following minor patch to codebook.c totally eliminates __divdi3
from my profile:
C:\xiph\vorbis\lib>cvs diff -u codebook.c
Index: codebook.c
==================================================================RCS file:
/usr/local/cvsroot/vorbis/lib/codebook.c,v
retrieving revision 1.39
diff -u -r1.39 codebook.c
--- codebook.c 28 Jun 2002 22:19:35 -0000 1.39
+++ codebook.c 22 May 2003 00:28:48 -0000
@@ -451,9 +451,10 @@
return(0);
}
-long vorbis_book_decodevv_add(codebook *book,float **a,long offset,int ch,
+long vorbis_book_decodevv_add(codebook *book,float **a,long _offset,int ch,
oggpack_buffer *b,int n){
- long i,j,entry;
+ int offset = (int)_offset;
+ int i,j,entry;
int chptr=0;
for(i=offset/ch;i<(offset+n)/ch;){
-Dave
--- >8 ----
List archives: http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to
'vorbis-dev-request@xiph.org'
containing only the word 'unsubscribe' in the body. No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.
Attached is a patch to codebook.c to add some explicit casts to ogg_int32_t. On some platforms, multiplication and division of longs is slower than ints; from looking at the code, it's expecting longs to be at least 32 bits wide, so ogg_int32_t is a safe choice. In a few places, the code was doing int quantvals = long * long, so I cast the operands to int instead of ogg_int32_t for clarity. These minor changes eliminated __divdi3 and __muldi3 from my profiles entirely (and should help on other 64-bit machines that still only have 32-bit multipliers and dividers). I still think the codebook structures should be changed to ogg_int32_t or whatever type is more suitable because I presume they're wasting memory bandwidth on platforms where sizeof(long) > sizeof(int). I'll look into doing this myself next. -Dave -------------- next part -------------- A non-text attachment was scrubbed... Name: codebook-long-patch.gz Type: application/x-gzip Size: 934 bytes Desc: codebook-long-patch.gz Url : http://lists.xiph.org/pipermail/vorbis-dev/attachments/20030522/a610f0d4/codebook-long-patch-0001.bin