Hacker News Reader

Comment by valarauca1 | Hacker News Reader

So does this attempt to better utilize the multiple compute units which make up a single compute pipeline? For example Skylake technically has 4 FPU's per physical core 1 SIMD, 3 x87 FPU-esque units, 1 branch processors, and 3-4ish IPU's (branch processors have some IPU uOPs)?

Or is it just a compiler integrated green thread library?

The FAQ is really vague just says its makes interfacing with parallelism easier.

View on HN

It started as a very simple green-parallelism library (spawn/sync/for), but it looks like it has been expanded to include an array syntax for c (a[:] = sqrt(b[:])*c[:])), which will automatically vectorize if possible. It also has`#pragma simd` to hint to the compiler that you want a code block to be vectorized, even if the compiler would otherwise not.

There's something about 'hyper objects' too which sound like race-condition safe objects for doing things like reductions.

For example Skylake technically has 4 FPU's per physical core 1 SIMD, 3 x87 FPU-esque units, 1 branch processors, and 3-4ish IPU's (branch processors have some IPU uOPs)?

Maybe I'm misunderstanding, but that's a very odd description of the execution units in a Skylake core. It might be better to say: "Skylake can sustain execution of 4 instructions per cycle, up to three of which can perform 256-bit vector operations." Section 2.1 here gives an exact diagram: http://www.intel.com/content/dam/www/public/us/en/documents/...

It's a fine-grained (green) threading runtime and language extension. Here's one of the original papers on Cilk: [1]. The programming model is completely independent of, and orthogonal to, whatever microarchitecture the pipeline has (and in fact out-of-order execution gets you benefits from multiple EUs for free, ish, modulo any SIMD optimizations you might do).

[1] http://www.cs.cmu.edu/~chensm/Big_Data_reading_group/papers/...

More of the latter, from what I've skimmed at least.

Cilk was a language originally developed for parallelism by MIT, they developed a Cilk Plus revision, and it later adopted by Intel as Cilk++ (where they added more functionality and a few keywords). This is basically an OSS implementation of the language without all the "good stuff" that comes with the Intel Compiler. You get green threads (fibers in Intel's lexicon), an acceptable malloc which is swapped in thought appropriate, real threading (which marks off critical sections in the conventional fashion) as necessary, and the ability to use spawn/async (a conventional barrier-wait thinger).

They say "SIMD[check]" so in theory there are all of those AVX512 with the SIMD stuff (xmm0,16..ymm0-32? It's been a while since I've looked at the ISA) in here but I went through the code briefly and saw no reference to utilization of those registers. This page is really doing a real disservice to the language because where it really shines is in the tooling that integrates with the language. The Parallel Suite XE (priced around Visual Studio) lets you get some crazy-granular stuff for traditional number--crunching that GCC and LLVM doesn't produce (effectively leaving those registers unused). With ICC, to state the obvious, you get that functionality, as well as all the fantastic cluster analysis stuff. (n.b. VS with TPL does a not-too-bad-job at utilizing the AVX(edit: put in "AVR" originally ugh haha) subset of the ISA.)

edit: https://bitbucket.org/intelcilkruntime/intel-cilk-runtime/sr... Yeah.. not too much processor specific stuff. In that dir, a few files showed the impl details of their threads which was just a conventional mov $1, rax; mov $2,rbx, blah blah. Nothing special. There are references to the 'special sauce' (vla references) left in the code from "if __INTEL__COMPILER__" macros, so I'm guessing it's just a copy-paste. Shame, it's a great language/toolset.

Reply on news.ycombinator.com