COMMENTS
Any one tried this it on a mac os
Several things intrigue me. First off, Cilk++ is described as based around GCC 4.2.4. The current GCC is 4.3.2. Does the description need an update, the core of Cilk++, or neither (if the difference doesn't impact anything Cilk++ does)?
Secondly, the blog talks a lot about multicore (one technology) and multithreading (two different technologies, depending on whether it's Intel's CPU threading or Linux' OS threading), but doesn't mention SMP (superior to multicores in some cases as you don't share caches or I/O lines). How well does it optimize for CPU threading or SMP systems?
It should be very easy for Cilk++ on Linux to transparently take advantage of something like MOSIX or Kerrighed for process migration, then use TIPC to create the illusion all of the activity is still on one box. No extra keywords need apply, but the optimization would be very specific to Linux with a specific migration system in place, so it's unclear the effort needed would be worth it. Unclear but not impossible. Have you considered it?
As Cilk++ presumably impacts the central compiler engine far more than it impacts the GCC frontends, you could presumably add other language frontends. Adding tokens for three keywords should not be that difficult, so long as the frontend is clean and well-designed. Now, I can't say I can think of too many who'd want a Cilkified PL/I compiler, but given how heavily the Fortran compiler is used for heavy maths, that could be a little more interesting. Is this something on your TODO list, or something you might add to it?
Lastly, to simplify circulation, have you considered offering the Open Source version as a binary package for Fedora or Debian/Ubuntu systems? If you'd consider the possibility, I'd be happy to provide the packaging files.
@ Mitesh
We don't have any plans to support Mac at this time. I'm a Mac user, myself, so I'd really like to see Cilk++ on Mac for my own projects. I tried to build it on my computer (Intel-based MacBook Pro) the other night for curiosity's sake. The build failed.
I don't know how much it would take to make it work and I intend to look into it further when I have time. But if you're interested, you can download the source and see what can be done. As I say, we don't support Mac right now, but GCC is GPL, and the runtime is CAPL.
@Jonathan,
(I’ll post each of your questions in italics, followed by my reply)
Several things intrigue me. First off, Cilk++ is described as based around GCC 4.2.4. The current GCC is 4.3.2. Does the description need an update, the core of Cilk++, or neither (if the difference doesn't impact anything Cilk++ does)? We've made significant changes to the GCC compiler. Since most developers change compilers slowly, we opted to target a slightly older release for Cilk++ 1.0. We do plan to track the GCC revisions over time to meet customer needs.
Secondly, the blog talks a lot about multicore (one technology) and multithreading (two different technologies, depending on whether it's Intel's CPU threading or Linux' OS threading), but doesn't mention SMP (superior to multicores in some cases as you don't share caches or I/O lines). How well does it optimize for CPU threading or SMP systems? Cilk++ works well on both SMP (symmetric multiprocessing) and CC-NUMA (cache-coherent nonuniform memory access) architectures. If there is sufficient parallelism in the application, the Cilk++ runtime system guarantees to exploit locality near optimally.
It should be very easy for Cilk++ on Linux to transparently take advantage of something like MOSIX or Kerrighed for process migration, then use TIPC to create the illusion all of the activity is still on one box. No extra keywords need apply, but the optimization would be very specific to Linux with a specific migration system in place, so it's unclear the effort needed would be worth it. Unclear but not impossible. Have you considered it? MOSIX and Kerrighed are far too heavyweight to use for Cilk++. Cilk++ creates and destroys parallel strands of execution at a cost of about 4 C++ function calls. The thinnest of parallel loops with only 1000 iterations are worthwhile to parallelize in Cilk++, and a fat loop can be parallelized with a granuality of 1.
As Cilk++ presumably impacts the central compiler engine far more than it impacts the GCC frontends, you could presumably add other language frontends. Adding tokens for three keywords should not be that difficult, so long as the frontend is clean and well-designed. Now, I can't say I can think of too many who'd want a Cilkified PL/I compiler, but given how heavily the Fortran compiler is used for heavy maths, that could be a little more interesting. Is this something on your TODO list, or something you might add to it? In fact, our changes are spread throughout the compiler. We are interested in supporting other languages and platforms, but our motivation to do so must be driven by customer demand. One of the reasons we're releasing our software under open-source licenses is so that people can make progress on their own with our technology, even if our own business priorities preclude us from doing the work.
Lastly, to simplify circulation, have you considered offering the Open Source version as a binary package for Fedora or Debian/Ubuntu systems? If you'd consider the possibility, I'd be happy to provide the packaging files. That's a great idea! We'd appreciate the help – feel free to contact us at info[at]cilk.com to discuss details.
Cheers,
Charles
I'm planning to port cilk++ application on MAC OSX.. so , where can i get the source code that can be modified inorder to make cilk++ work on MAC OSX
Can any one tell me what are the dependencies for running Cilk++ sucessfully on a linux machine?
I just want to know what other files Cilk++ uses to run successfully on a linux package