ogg dev - Feb 2008 - OggPCM: support for little-endianness only?

Timothy B. Terriberry wrote:
> It doesn't even really matter which architecture you're actually
on. In
> any format that is to be used on both, it is always better to pick one
> and stick with it. Otherwise you require _both_ architectures to write
> additional code that is largely useless. Unless you can guarantee that
> you're writing streams that are only going to be passed within a single
> architecture, allowing both formats is always worse. That happens seldom
> enough in practice and has a small enough benefit that it is in no way
> worth making everyone else do extra work.
For a compressed format I would agree 100%, but PCM is not a compressed
format; its a format that if the endian-nesses of the file and CPU match,
can be dumped from file to disk and disk to file without any processing.

In libsndfile I handle this by doing a straight read or write when the
endian-nesses match and endswapping where I have to. For a data format 
as simple as PCM the minor effort required for a couple of different code 
paths is well worth it for the performance payoff.

Erik
-- 
-----------------------------------------------------------------
Erik de Castro Lopo
-----------------------------------------------------------------
"We can build a better product than Linux" -- Microsoft
Corp.'s Windows operating-system chief, Jim Allchin.
One has to wonder why, with their huge resources, they haven't.
-- 
-----------------------------------------------------------------
Erik de Castro Lopo
-----------------------------------------------------------------
"So if you were to say 'Microsoft,' I'd say 'Where? Let me
grab
me my stake and crucifix!'." -- Bridget Kulakauskas

> For a compressed format I would agree 100%, but PCM is not a compressed
> format; its a format that if the endian-nesses of the file and CPU match,
> can be dumped from file to disk and disk to file without any processing.
> 
> In libsndfile I handle this by doing a straight read or write when the
> endian-nesses match and endswapping where I have to. For a data format 
> as simple as PCM the minor effort required for a couple of different code 
> paths is well worth it for the performance payoff.
Really? How low does it take to swap bytes vs. the time it takes to read
from disk? Unless I'm missing something, the read speed is limited by
the disk bandwidth (~100 MB/s max) while the swapping is only limited by
the memory speed (5+ GB/s now).

	Jean-Marc

Jean-Marc Valin wrote:
> Really? How low does it take to swap bytes vs. the time it takes to read
> from disk?
In CPU cycles? The difference is enormous.

If no byte swapping is required the vast majority of the work is done by
the DMA engine, from disk straight into user space memory and while the
read is underway, the CPU can do other work.

For the byte swapping case, every sample needs to be loaded into the cache
and CPU, byte swapped and then written back to memory.

Erik
-- 
-----------------------------------------------------------------
Erik de Castro Lopo
-----------------------------------------------------------------
I have now spent two days debugging C# on dotnot and all I can say
is OMFG!!!! The MS tools are completely fucking abysmal. Its the
most developer hostile environment I've ever worked on. The fact
that people are actually able to release software that sort of
works using these tools completely boggles my mind.