Intel Opens Up Cilk Plus hpcwire.com
Language could pave the way for native parallelism in C and C++.
Ok so the marketing consultants feel this is a good place to post the announcement, but I’m curious… Can anyone actually say they are using this in HPC? Do you think other vendors like PathScale/PGI should adopt it?
Seriously? When app SW and tools continues to be our greatest challenge,
you don’t believe this move might be of interest to the HPC community?
I’m seriously not kidding at all. Pragmatically speaking what problem does it solve that isn’t already solved? Sure I’ve only glanced at it, but 1) how much existing cilk code is used in HPC 2) how well does the programming model fit with GPU or a heterogeneous cluster (honest question) 3) Is there a test-suite that’s being opened as well 4) any empirical evidence showing a performance gain vs openmp or something comparable 5) when has Intel ever open sourced anything that was of any value..
IMHO it solves nothing and we have enough programing model proliferation as it is. Show me where I’m wrong and then we come back to my original question about if other vendors should implement it.
With my open source hat on it’s party time and I don’t want to come across as negative. With my HPC hat on I’m skeptical and we’ll see if helps them lock people in…
I think it is a good option. It does not solve everybody’s problem and will require some works. But it provides much better approches than patch directives that do not address the core issues of heterogeneous computing.
I don’t see Cilk solving anything in HPC. It looks like a great tool for thread programming and task parallelism. However, HPC is to a large extent data parallel. Watch the success of GPUs, which are data parallel monsters. Yes, they use threads, but these are generated in a data parallel way, not by the fork/join paradigm that Cilk is based on.
I would ask directly to Leiserson and Frigo what is Cilk’s contribution: finding a good solution of thread allocation to cores, no matter what cores or threads, it is a difficult and useful problem. In GPUs Cilks is not the preferred solution because other tools provide better scheduling. In general, I would say to write good parallel code the developer and the compiler have to work together. Cilk is an interesting attempt to do just that. Will see.
I think Cilk model of programming is suitable for irregular applications such as graphs, and sparse matrices. Its scheduler used to perform amazingly well when it used to be called CilkArts Cilk++ (about 2 years ago). I am happy with this move because the Cilk Plus embedded inside Intel’s compilers wasn’t as good (perhaps due to different stack allocation rules). The downsides of Cilk are that you can’t schedule arbitrary dags directly (yes, you can hack the system to do that but then it doesn’t perform well) and there is no NUMA aware stealing. Both of these shortcomings are intentional (if you ask Leiserson or Frigo) because you can’t get parallelism and optimality proofs without them. However, as Cilk becomes a practical tool than solely an academic paper machine, I think it’s time those constraints are relaxed.
I like the simplicity and elegance. It should promote cleaner code with less debugging. I think some versions (shared memory?) of the FFTW package (quite popular in HPC space) was written using Cilk.
I now post my TRADING ALERTS
into my personal FACEBOOK ACCOUNT
. Don't worry as I don't post stupid cat videos or what I eat!