[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