ippsNot_16u instability

[Adriaan_van_Os]

IPP has ippiNot_8u, but it doesn't have the equivalent ippiNot_16u calls. However, there are ippsNot_16u routines. So, I created an equivalent for the missing ippiNot_16u_C1R with ippsNot_16u. However, this caused random crashes of my software. The crashes disappeared when I replaced ippsNot_16u with a hand-written equivalent. Also, there a no problems with ippiNot_8u_C1R, that I use frequently.

The issue is difficult to reproduce, but my conclusion is that ippsNot_16u has some kind of internal problem, that lets it crash randomly.

Regards,

Adriaan van Os

[Chao_Y_Intel]

Adriaan, 

What's the processor you notice the problem on.  If it is hard to reproduce this issue, one thing we can check is to work with our engineer owner to have quick review on that specific processor code, and see if there is anything we can find. 

Thanks,
Chao
 

[Adriaan_van_Os]

Thanks for looking into this. It's a 2.2 Ghz Intel Core i7. Should I try another config (on the same hardware) ?

  Number Of Processors:    1

  Total Number Of Cores:    4

  L2 Cache (per core):    256 KB

  L3 Cache:    6 MB

  Memory:    4 GB

Regards,

Adriaan van Os

[Adriaan_van_Os]

As a side-note, I can add that I am using 509 different ippi functions in my code and one ipps function. This is one of the few instabilities I have run into.

Regards,

Adriaan van Os

[Igor_A_Intel]

Hi Adriaan,

could you provide an output from the "get library version" function?:

    const IppLibraryVersion *lib;

    lib = ippsGetLibVersion();
    printf( "CPU       : %s\n", lib->targetCpu );
    printf( "Name      : %s\n", lib->Name );
    printf( "Version   : %s\n", lib->Version );
    printf( "Build date: %s\n", lib->BuildDate );

regards, Igor

[Adriaan_van_Os]

I tried with both

CPU       : g9

Name      : ippSP AVX (g9 threaded)

Version   : 2018.0.2 (r57678)

Build date: Jan 23 2018

and

CPU       : g9

Name      : ippSP AVX (g9 threaded)

Version   : 9.0.2 (r49912)

Build date: Dec 28 2015

But most of the time, the function does not crash, even with the same data. So, it is difficult to reproduce.

Regards,

Adriaan van Os

[Igor_A_Intel]

Hi Adriaan van Os,

It's difficult to find bugs (even if they exist) without a reproducer. Our tests have not shown any issues in the code of ippsNot_16u function. Please try the next workaround (instead of non-existing ippiNot_16u_C1R):

IPPAPI(IppStatus, ippiXorC_16u_C1R, (const Ipp16u* pSrc, int srcStep, IPP_MAX_16U, Ipp16u* pDst, int dstStep, IppiSize roiSize))
please note: ippsNot_16u has the similar implementation in SP domain:

IPPFUN(IppStatus, ippsNot_16u_I, (Ipp16u* pSrcDst, int len))
{
    return ippsXorC_16u_I(IPP_MAX_16U, pSrcDst, len);
}

IPPFUN(IppStatus, ippsNot_16u, (const Ipp16u* pSrc, Ipp16u* pDst, int len))
{
    return ippsXorC_16u(pSrc, IPP_MAX_16U, pDst, len);
}

regards, Igor.

[Adriaan_van_Os]

It was my fault, I apologize. The headers specify the "len" parameter as the "length of the vector" which I understand as the length of the vector in bytes. The manual however specifies "len" as the "number of elements in the vector". After changing the "len" parameter to the number of elements, the function is stable.

You may want to clarify the header text and rename  "len" to "num".

Regards,

Adriaan van Os

[Ruqiu_C_Intel]

Hello Adriaan van Os,

Thanks for your comment. We will discuss it very carefully.

Best Regards,

Ruqiu