[asterisk-users] Use the NEW ulaw/alaw codecs (slower, but cleaner)

[Steve Underwood]

Matthew Fredrickson wrote:
> Actually, with the way caching is done on nearly all modern processors, 
> it is debatable whether or not a look up table is the optimal way to do 
> the conversion, at least on such a simple codec such as ulaw or alaw. 
> In fact, the amount of time it takes to fetch memory from a cache miss 
> can easily ruin the single element lookup performance in a look up 
> table.  And if you have large tables (such as in the linear to ulaw or 
> alaw table), the tradeoff of having to service a cache miss versus a few 
> cached instructions executing a native CPU clock speed makes it almost a 
> no brainer (IMHO).
>
> You'll pay a cache miss on the first time your run the routine, but the 
> instructions running the routine will take up much less CPU cache space 
> than the look up tables, increasing the likelihood of them being evicted 
> (whereas the lookup table, taking up a lot more space, has a much better 
> chance of causing a cache miss whenever you access).
>
> Obviously, if you're running on a CPU with no cache, a look up table is 
> a good way to do it.  I'm just saying that very few processors that are 
> running Asterisk are running it on processors without processor caches.
>
> Matthew Fredrickson
> Digium, Inc.
>   
In spandsp I do the G.711 conversions algorithmically. Most modern 
processors have a "where is the top 1" instruction, and that reduces the 
calculations to something very fast. When I first did this it was a lot 
slower than a lookup if I tested it on its own, but faster in a real 
workload where the cache was working hard. That was in the days of 256k 
caches, though. Now the latest Intels have 12M the picture may be 
different. That 12M is L3 cache, which is a lot slower than the small L1 
cache, but I suspect it make mean the lookup approach is as good as 
calculation with any workload.

Steve