[mb-devel] audio fingerprinting part 2

Ben bench at silentmedia.com
Wed Oct 12 01:10:53 UTC 2005


Heh, I keep forgetting about and re-learning about this library.  
Maybe some day I'll actually use it and then I'll stop forgetting  
about it.

But, alas, it will not help reduce the problem below O(n). It may  
speed things up 4-fold or even more. That's pretty significant. Add  
some other optimizations people have talked about and you get even  
more milage from the same algorithm. But sooner or later (actually,  
with MB's size, pretty soon), either the matching algorithm will have  
to change or hardware will have to be added.

Unlike TRMs, fdmf is great in that hardware *can* be added. it's an  
ideal problem for parallel computing. It's just that parallel  
computing isn't cheap.

On Oct 11, 2005, at 2:20 PM, Colin Marquardt wrote:

> Ben <bench at silentmedia.com> writes:
>
>
>> 1. CPU time. fdmf is not a cheap solution. Unless better minds
>> propose something faster than what I came up with, it will be too
>> expensive to run on a single machine.
>>
>
> You guys probably know about this, but I'm pointing to it anyway,
> without knowing if it's at all appropriate:
>     http://www.schleef.org/liboil/
>
> | Liboil is a library of simple functions that are optimized for
> | various CPUs. These functions are generally loops implementing
> | simple algorithms, such as converting an array of N integers to
> | floating-point numbers or multiplying and summing an array of N
> | numbers. Such functions are candidates for significant optimization
> | using various techniques, especially by using extended instructions
> | provided by modern CPUs (Altivec, MMX, SSE, etc.).
>
> Cheers,
>   Colin
>
> -- 
> NP: Devin Townsend's Terria - The Fluke
>
> _______________________________________________
> MusicBrainz-devel mailing list
> MusicBrainz-devel at lists.musicbrainz.org
> http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-devel
>




More information about the MusicBrainz-devel mailing list