vtsynergy/opendwarfs

The OpenDwarfs project provides a benchmark suite consisting of different computation/communication idioms, i.e., dwarfs, for state-of-art multicore and GPU systems. The first instantiation of the OpenDwarfs has been realized in OpenCL.

opendwarfs's Issues

.

Hi,
I am having problem compiling when OpenCL headers are located in an alternate location. Any Suggestion.

Would you mind sharing the parameters of the results provided?

Would you mind sharing the parameters of the results provided? For example, which .txt you used to generate the result csv for "bfs", or which group of parameters you used for "bwa_hmm"? I would like to compare my results with yours.

How to provide arguments

Hi,

As per README,
To run astr:

Usage: astar [ | --]

:integer ID of platform to use
       :integer ID of device in to use
    : device type to use (0:CPU, 1:GPU, 2:MIC, 3:FPGA)

If I want to run on GPU what should I specify?

./astr -- t 1 Doesn't work.

Do I need to specify all the options? platform, device and type.
Please provide example command with different options (specifically to
target a particular device).

Cheers

libtool failure "-Lyes"

After running autogen.sh, I configure with ../configure --prefix=/scratch/cchang/opendwarfs --with-opencl
make fails with

  CXXLD    gemnoui
./libtool: line 6000: cd: yes: No such file or directory
libtool: link: cannot determine absolute directory name of `yes'
make[1]: *** [gemnoui] Error 1

Without the --with-opencl, the build succeeds. Configure still finds cl.h regardless, and a number of "*.cl" binaries are being created.

I am trying to build against CUDA 10.2.89, built from source with Spack.

Error when linking

I am trying to build this on Ubuntu 14.04 system, gcc 4.8 and Intel OpenCL 1.2. Essentially when the program gets to the linking phase I obtained the following error:

/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/libm.so: error adding symbols: DSO missing from command line

Which is due to the order of the libraries in the compilation stage. However, I am probably running a too new of a setup for the benchmarks. Can you please report on what systems have this been successfully run? Fedora, CentOS? What gcc version was used.

Thank you

test/sparse-linear-algebra/SPMV/csrmatrix_R1_N4_D500000_S01 not found

Can you please add the data set test/sparse-linear-algebra/SPMV/csrmatrix_R1_N4_D500000_S01 as explained in the README file to the repository?

Why not use a permissive license?

Licensing under LGPL v2.1 means that most companies won't touch it with a barge pole.

Is there a mapreduce benchmark?

There is a file test/mapreduce/fsa-blastcl/test.fasta
Is there a benchmark that uses this file?

I get this error on running ../configure --with-apps=kmeans then I make k means and I get this next error:

Compiler errors, please help

When I compiled the application "csr" with the command line "./configure --prefix=$HOME --with-apps=csr", I got the errors below (it seems that two types do not match). Even if I added the opencl-sdk path to the command line "./configure --prefix=$HOME --with-apps=csr --with-opencl-sdk=/opt/intel/opencl-sdk", I still got these errors. Any help is appreciated!

include/common_args.c: In function ‘ocd_finalize’: include/rdtsc.h:235:34: error: format ‘%llu’ expects argument of type ‘long long unsigned int’, but argument 2 has type ‘cl_ulong {aka long unsigned int}’ [-Werror=format=] #define OCD_PRINT_TIMERS {printf("********************************************************************************\n"\ ^ include/rdtsc.h:273:5: note: in expansion of macro ‘OCD_PRINT_TIMERS’ OCD_PRINT_TIMERS\ ^ include/common_args.c:258:2: note: in expansion of macro ‘TIMER_PRINT’ TIMER_PRINT ^ include/rdtsc.h:235:34: error: format ‘%llu’ expects argument of type ‘long long unsigned int’, but argument 3 has type ‘cl_ulong {aka long unsigned int}’ [-Werror=format=] #define OCD_PRINT_TIMERS {printf("********************************************************************************\n"\ ^ include/rdtsc.h:273:5: note: in expansion of macro ‘OCD_PRINT_TIMERS’ OCD_PRINT_TIMERS\ ^ include/common_args.c:258:2: note: in expansion of macro ‘TIMER_PRINT’ TIMER_PRINT

issue in hmm kernel

When the algorithm calculates the scaling factor in estimate_b in main_bwa_hmm.c @ line 871-872, the states are treated as the rows and the symbols the columns.
mat_vec_mul( 'N', nstates, nsymbols, b_d, nstates,
ones_s_d, 0, c_d, 0);

But in the kernel the indexing scheme seems to suggest the reverse:
if (idx < nstates && idy < nsymbols)
{
if (b_d[(idy * nstates) + idx] == 0)
{
b_d[(idy * nstates) + idx] = 1e-10;
}
else
{
b_d[(idy * nstates) + idx] = b_d[(idy * nstates) + idx] / c_d[idx];
}
}

Shouldn't the matrix be transposed and then multiplied or the kernel be changed? Otherwise we get a division by zero (after we change the 'N' to 'n', see issue #3 .

bug in graphical models(hmm)

In main_bwa_hmm.c lines 871 and 872 we have an uppercase 'N' as the first argument:
mat_vec_mul( 'N', nstates, nsymbols, b_d, nstates,
ones_s_d, 0, c_d, 0);

but mat_vec_mul ignores all arguments other than 'n' and 't' on line 339 of the same file.

I don't get consistent results between runs with "-v n -n 60" unless I change it to 'n'. I think the change yields the proper results

Definitions of min/max macros conflict with stl_algobase.h

  CXX      n-body-methods/gem/gemnoui-calculate_potential.o
In file included from /nopt/nrel/apps/base/2020-05-12/spack/opt/spack/linux-centos7-x86_64/gcc-4.8.5/gcc-8.4.0-xrmnckz436rnkcwooooi2r7n35pojkov/include/c++/8.4.0/bits/char_traits.h:39,
                 from /nopt/nrel/apps/base/2020-05-12/spack/opt/spack/linux-centos7-x86_64/gcc-4.8.5/gcc-8.4.0-xrmnckz436rnkcwooooi2r7n35pojkov/include/c++/8.4.0/ios:40,
                 from /nopt/nrel/apps/base/2020-05-12/spack/opt/spack/linux-centos7-x86_64/gcc-4.8.5/gcc-8.4.0-xrmnckz436rnkcwooooi2r7n35pojkov/include/c++/8.4.0/ostream:38,
                 from /nopt/nrel/apps/base/2020-05-12/spack/opt/spack/linux-centos7-x86_64/gcc-4.8.5/gcc-8.4.0-xrmnckz436rnkcwooooi2r7n35pojkov/include/c++/8.4.0/iostream:39,
                 from ../n-body-methods/gem/calculate_potential.cpp:25:
/nopt/nrel/apps/base/2020-05-12/spack/opt/spack/linux-centos7-x86_64/gcc-4.8.5/gcc-8.4.0-xrmnckz436rnkcwooooi2r7n35pojkov/include/c++/8.4.0/bits/stl_algobase.h:243:56: error: macro "min" passed 3 arguments, but takes just 2
     min(const _Tp& __a, const _Tp& __b, _Compare __comp)

In n-body-methods/gem/include/calculations.h, if I comment out the definitions, the build will proceed before

  CXXLD    gemnoui
./libtool: line 6000: cd: no: No such file or directory
libtool: link: cannot determine absolute directory name of `no'

Related to issue #16, where I get "yes" instead of "no", so seems like a Boolean variable is being used instead of a path variable (since this build is --without-opencl).

Missing return in function

Hello,

I downloaded OpenDwarfs and tried to compile on Mac OS X following the README instructions, then I got the error:

../include/common_args.c:231:1: error: control reaches end of non-void function
[-Werror,-Wreturn-type]

To correct this error, just add a return 0; to the line 231 of the file common_args.c and it will compile, but you need either to correct the function signature and change int to void, or supply the correct returns inside the function.

2D clfft segfault

Hi folks,

I've extended the clfft code in my branch to accept arbitrary powers of 2 arguments for both the 1 and 2D use cases. In doing this I noticed there is a potential bug in a code path not currently hit. However if in the future you need to select problem sizes greater than 128 elements in the 2nd dimension, like so, ./clfft -p 0 -d 0 -t 0 -- --2D --pts1 8192 --pts2 256 then you'll get a segmentation fault. After a full day of hacking on this code, I noticed that the reason for this is an incorrect input and output offset in the fft2 kernel. This offset is actually generated in determining the local and global workgroup sizes at line 470 of fftlib.cpp. The bug is in the function getGlobalDimension(localsz1, globalsz1, fftn1, fftn2, 0); which is undocumented and quite gnarly. I believe this is a typo since this is the only location the 3rd argument (here fftn1) is set to be anything else other than 1. I believe this argument is for the preferred local workgroup size, and the last argument indicates whether a vertical or horizontal kernel invocation is needed. Thus it returns arg1 being the localWorkgroup size, and arg2 is the numberOfWorkgroups required. This is converted from CUDA style to the OpenCL style in the next line with globalsz2 = globalsz2 * localsz2;.

I've corrected it in my branch, but if you don't approve my pull request I'd suggest changing it to getGlobalDimension(localsz1, globalsz1, 1, fftn1, 0); on line 465 and getGlobalDimension(localsz2, globalsz2, 1, fftn2, 1); on 470.

Additionally, I don't believe this was based off the SHOC codes as indicated in the README, since SHOC only performs 1D computation. It is however very close in implementation to the paper presented here. I just wish I could find the code base on which this was adapted.

Beau.

p.s. the relevant changes can be found in this commit

/usr/bin/ld: skipping incompatible /usr/lib//libOpenCL.so when searching for -lOpenCL

I get this error on running ../configure --with-apps=fft.
On finding the error results on google, it suggests architecture incompatibility.
Could you suggest a way out?