I have an issue with the OpenMP implementation "GOMP" (namely GNU OpenMP), running on a Microblaze processor. The MicroBlaze processor is in the kernel mainline, and Xilinx provided pthread implementation for it. So I cross-compiled the GOMP library starting from pthread implementation and inserted in the Linux kernel running on Microblaze (that is a 3.10 version, named Petalinux). Specifically, the problem is highlighted running one of the Parsec benchmarks (here is the link (http://parsec.cs.princeton.edu/download.htm)), namely blackscholes. The code section that shows problem is the following:

int bs_thread(void *tid_ptr) {
    int i, j;
    fptype price;
    fptype priceDelta;
    int tid = *(int *)tid_ptr;

    for (j=0; j<NUM_RUNS; j++) { 
#pragma omp parallel for private(i, price, priceDelta)
        for (i=0; i<numOptions; i++) {

            price = BlkSchlsEqEuroNoDiv( sptprice[i], strike[i],rate[i], volatility[i], otime[i], otype[i], 0);
            prices[i] = price;
            } 
    } 

return 0;

}

blackscholes can be launched with different input sets, and different thread numbers, with the command: blackscholes _num_threads_ _input_file_ _output_file_

Launching it with 1, 2, 3, 5, 7 threads and so on, following odd numbers, it works good. Launching it with 4, 6, 8, 10 threads and so on, following even numbers, it blocks. Again, by reducing the constant NUM_RUNS to 1, the application works good. My question is: is it possible that the GOMP implementation suffers of worksharing construct insertion (namely omp parallel for) after a for cycle?

Thank you.

0

There are 0 best solutions below