AMD support & multithreading

[gol]

Hi there.

I have4 quick questions:

-I own an AMD (because I have 3DNow code to maintain and because well, I prefer its FPU performances). Fortunately the IPP seems to give a nice speedup on it, so I'm assuming that even though it has no direct optimized support for AMD's, it does let it run SSE and/or SSE2 code.
So I'm asking: this support won't go in the future, right?

-We use static linking (to reduce download size) and I just read there's no multithreading available with static linking. I was just wondering the reason of that?

-Our application (sequencer) defaults to 80bit FPU precision (because, why not?), but I read the IPP are designed for 64bit precision.
I wouldn't like to have tochange the FPU state before calling IPP functions, so I'm asking, is it just a matter of functions returning a higher precision than declared? If so, I have no prob with that. Or can it really lead to very erratic results?

-I'm surprised there's no Threshold_LTAbsVal function, because, isn't it common to set close-to-tiny-numbers to zero to avoid denormalization? Or course LTAbs works, but it's better to force to zero as a real zero signal can be quickly recognized & bypassed if possible.
Not really a problem as I have my own all-integer function to do this, though.

thanks

[Vladimir_Dudnik]

Please find my comments below

gol:

Hi there.

I have4 quick questions:

-I own an AMD (because I have 3DNow code to maintain and because well, I prefer its FPU performances). Fortunately the IPP seems to give a nice speedup on it, so I'm assuming that even though it has no direct optimized support for AMD's, it does let it run SSE and/or SSE2 code.
So I'm asking: this support won't go in the future, right?
VD> it will. Ipp supports cpu by features, not by company name

-We use static linking (to reduce download size) and I just read there's no multithreading available with static linking. I was just wondering the reason of that?
VD> several ones, one of them is driver support

-Our application (sequencer) defaults to 80bit FPU precision (because, why not?), but I read the IPP are designed for 64bit precision.
I wouldn't like to have tochange the FPU state before calling IPP functions, so I'm asking, is it just a matter of functions returning a higher precision than declared? If so, I have no prob with that. Or can it really lead to very erratic results?
VD> almost in all the cases ipp doesn't change cpu precision meaning customer setting will work

-I'm surprised there's no Threshold_LTAbsVal function, because, isn't it common to set close-to-tiny-numbers to zero to avoid denormalization? Or course LTAbs works, but it's better to force to zero as a real zero signal can be quickly recognized & bypassed if possible.
Not really a problem as I have my own all-integer function to do this, though.
VD> the function is not about "close-to-tiny" (can be used though), it is just convetional functionality

thanks