Intel IPP and headers

[janlund1967]

Hi.

For quite some time i have been looking for some software with the capabilities that IPP have. Then i found IPP which claims to be able to be used from almost any programming language available :o)

Although it might be possible to use it from any language,i sincerely doubt that you (Intel) will get a lot of customers outside the Cworld, due to the lack of headers for other languages than C.

I know that you can't make headers for every existing language, but you should at least make it for the languages you claim to support.

I am a Delphi developer, and i have been looking at the Delphi example, which has 12 functions translated. The IPP has 800+ different functions, and it will be too much work for me (and other Delphi and/orVisual Basic)developers to translate these headers - simply because you have to learn both the C language and the capabilities of IPP at the same time.

For comparison, i could have written this mail in my native language (Danish) and the readers of this post might have understood some of it, but it would be too much work if all of them had to translate it into english in order to understand what i am writing. Even if someone tried, they most likely wouldn't get it right, because of the lack of knowledge to the "specialties" in the danish language. Now i did the translation - it is certainly not 100% correct :o)- but hopefully correct enough to understand for the majority of readers.

In the same way, a translation of the C headers into Delphi or Visual Basic will most likely fail for the average Delphi/VB developer sinceyou really need a good knowledge of C in order to do it correctly.

So - my question is :

Why don't you make these headers and expand your market segmentalso to contain Delphi and VB developers ?

If you got this far : Thank you very much for your patience ;o)

Yours sincerely

Jan Lund

[borix]

Hi Jan,

your translator is perfect (not sure about mine)

in the Samples released with IPP you can find vbinvoke sample. It contains full interface to VB (.NET) for several IPPdomains, in particular for signal and image processing, for jpeg primitives and for string processing as well as an example of the use it.

in the sample delphiomp you definitely find more than 12 functions, and the same in Linux, so more twice :) I don't say at all that it is a threading example

in 5.0 you will get one more interface for IPP

regarding the question why not full interface for IPP in Delphi, well, you know, "too much work" as you said. before releasing even one wrapperyou have to test it before, right?

thank you

Boris

[janlund1967]

Hi Boris.

Thanks for your reply.

>in the Samples released with IPP you can find vbinvoke sample. It contains
>full interface to VB (.NET) for several IPP domains

That sounds great. I'll look into that and see if am able to use it from Delphi 2005 (.NET) then, if the .NET wrappers are implemented. Do you know if the IPP-performance is the same using .NET compared to native Win32 ?

>in the sample delphiomp you definitely find more than 12 functions

Well - there might be 13 or 14 (but in different variations totalling to maybe 50), and then of course the datatypes and structures has been translated.

The sample i talk about is the one called w_ipp-sample-Delphi_p_4.1.005.zip
Is there another one ?

>regarding the question why not full interface for IPP in Delphi, well, you know, >"too much work" as you said. before releasing even one wrapper you have to >test it before, right?

Well - yes, but i would be satisfied with less.

I would be happy if the translation were done completely (most of the translation could be done automatically) and, lets say, that one variation of each function was tested. Then you would have a pretty good chance that the other variations works, since most of them has the same parameters (although different data types).

For example the ippiRGBToXYZ function has 8 different variations.

8u_C3R 16u_C3R 16s_C3R 32f_C3R
8u_AC4R 16u_AC4R 16s_AC4R 32f_AC4R

If all of them were present in the header file (ippi.pas), but it was stated somewhere that only the 8u_C3R variation has been tested, then
you would have a chance of getting something to work at least with the 8u_C3R version without worrying about you had done a bad translation.

The step from 8u_C3R to 32f_C3R is then a fairly small one, and if for some reason the automatic translation of the 32f_C3R should have failed, then it probably would be easy to spot.

It might even not be necessary to test one for each function, since a lot of similar functions tends to have the same parameters (ie. ippiSub, ippiAdd, ippiMul and ippiDiv has exactly the same set of parameters).

Here only one test would be sufficient, since this is not a test of the library, it is a test of the header translation.

If the error is in the library it will fail regardless of the programming language you are using.

Thanks
Jan