I'm currently working on a legacy system which has a computation model of dependency graph. I tried tbb::flow::graph, which works good.
However, there is a special case in our system: A node could start to reject all future messages after it "sees a certain kind of messages"*. (Its children will also reject messages if one of its parents start to reject) Is there a way to reject messages?
It appears that the compiler option -mfpmath=387 immediately causes floating point exceptions on Intel architecture processors in cilk_spawn routines compiled with gcc-5.1 cilk. This seems to be a regression as gcc-4.9 with the cilk patches works fine. Note that -mfpmath=sse works on 64-bit machines, however, this option is not available for 32-bit Intel machines. As far as I can tell, most floating point code is affected. Does anyone know of patches or workarounds for this, especially as this appears to be a show-stopper on 32-bit Intel.
In a four-state pipeline, I employ task parallelism in two stages.
I have two questions about WRITE/READ operations on shared arrays.
1) In my program I write a different element of a given shared array at every iteration of an OpenMP-parallelized DO LOOP. The results that I get should be right but I'm just wondering whether this is fine or I should enclose the READ/WRITE section in a CRITICAL block. Then, I also READ elements from a shared array without modifying them and it seems to work. Are these procedures correct?
I've made a DLL while I compile with /Qipo (Intel C++ Composer XE2015). If I call the constructor and destructor of the main class in it, the memory doesn't get released and after a few calls (32 bit mode) I'm out of memory. However, if I disable /Qipo, there doesn't seem to be a problem at all (I will run it for a longer period tonight, but I let it construct and deconstruct 1024 times earlier tonight and I didn't notice an increase in memory usage).
If I use /Qip mode, the leak is 8 MB per call. With /Qipo it's about 300 MB.
Since I haven't seen a notification of this elsewhere, the ever knowledgeable Jim Dempsey (QuickThreadProgramming.com) just published one of his great technical articles entitled, "Elusive Algorithms – Parallel Scan".
I believe this was an outgrowth of another discussion on the forums, "how to perform inclusive scan in C cilk".
Compiling OFED with with phi and --all fails when compiling compat-rdma. Compile without the "--with-xeon-phi" option works. ./install.pl --with-xeon-phi --all # cat /etc/redhat-release Red Hat Enterprise Linux Server release 7.1 (Maipo) # uname -r 3.10.0-229.1.2.el7.x86_64 rpm -qi mpss-sdk-k1om-3.5-1.x86_64 Name : mpss-sdk-k1om Version : 3.5 Release : 1 Architecture: x86_64 Install Date: Thu 09 Apr 2015 10:00:28 PM CDT Group : base Size : 484359036 License : various Signature : DSA/SHA1, Thu 02 Apr 2015 06:57:59 AM CDT, Key ID 718a1696ef328191
# ProductName: Mac OS X
# ProductVersion: 10.10.3
# BuildVersion: 14D136
curl -O https://www.openmprtl.org/sites/default/files/libomp_20150401_oss.tgz
gunzip -c libomp_20150401_oss.tgz | tar xopf -
in line 124..126 of libomp_oss/src/makefile.mk:
ifeq "$(os)" "mac"
mac_os_new := $(shell /bin/sh -c 'if ; then echo "1"; else echo "0"; fi')
Last month there was a query on the IDZ MIC forum "how to perform inclusive scan in C cilk" in which my initial reply was:
Parallelizing this is problematic due to the next result being dependent upon the prior result. While this is not impossible, it is rather difficult and it introduces some redundant additions.