SequenceL: A very simple parallel programming language(en.wikipedia.org)
en.wikipedia.org
SequenceL: A very simple parallel programming language
http://en.wikipedia.org/wiki/SequenceL
1 comments
I'm not the submitter, but I work with the people who write sequenceL and can answer questions about it.
I attended a session on SequenceL today at RTECC today [1] and was fairly impressed.
Some questions I have:
1. What are the licensing costs like for the compiler/runtimes?
2. Do you know how it works behind the scenes?
3. How much speed-up can be expected? I understand this is very specific to the application/algorithm at hand, and this is where #2 above helps.
4. Are there other such languages/systems?
[1] http://rtecc.com/
Some questions I have:
1. What are the licensing costs like for the compiler/runtimes?
2. Do you know how it works behind the scenes?
3. How much speed-up can be expected? I understand this is very specific to the application/algorithm at hand, and this is where #2 above helps.
4. Are there other such languages/systems?
[1] http://rtecc.com/
1. No idea--I think they're still working on pricing. They're eager to work with people, so I would just contact them if interested.
2 & 3. This is a topic for a research paper...and there have been a few if you want to dig deeper. Here's one from an ACM conference: http://www.texasmulticoretechnologies.com/content/2004_SL_Tr...
If you don't want to read the whole thing, here's a summary: there's a whole bunch of stuff the compiler does when it transforms SequenceL code into C++. For example, it's numa aware and takes advantage of sse and similar types of things where possible. They've seen that if a dedicated team has been hand tuning a particular algorithm in c++ for years (the sort of thing you might see in certain industries), the sequenceL generated code will probably not beat that--but, it might take a week to develop a version in SequenceL that runs at 80 to 90% of that speed.
The rest of the time (i.e. when compared to code that has not had a dedicated team devoted to hand optimizing the c++), they've found that the SequenceL generated code runs much faster and takes less time to develop than traditionally developed parallel code. This is for a few reasons: generally, most teams won't take the time to parallelize all the parts of their code than can possibly be parallelized. Thus, they run into a sort of self imposed Amdahl's law situation--those parts that they haven't spent time parallelizing eventually become, relative to the entire app, the part of the app that takes longest to run. This problem is seen more with larger core counts, of course. Second, many highly talented engineers who are world class in their own domain are not also world class at writing multithreaded c++, and so may not have written their own multithreaded / numa aware memory allocator, or optimized the sse widths correctly for different chip generations and so on.
In the end of course, it depends on the algorithm, and delving into the paper, or even better, contacting them any trying it out with your particular algorithm, would provide the best answers.
4. I'm not aware not aware of other such languages/systems.
2 & 3. This is a topic for a research paper...and there have been a few if you want to dig deeper. Here's one from an ACM conference: http://www.texasmulticoretechnologies.com/content/2004_SL_Tr...
If you don't want to read the whole thing, here's a summary: there's a whole bunch of stuff the compiler does when it transforms SequenceL code into C++. For example, it's numa aware and takes advantage of sse and similar types of things where possible. They've seen that if a dedicated team has been hand tuning a particular algorithm in c++ for years (the sort of thing you might see in certain industries), the sequenceL generated code will probably not beat that--but, it might take a week to develop a version in SequenceL that runs at 80 to 90% of that speed.
The rest of the time (i.e. when compared to code that has not had a dedicated team devoted to hand optimizing the c++), they've found that the SequenceL generated code runs much faster and takes less time to develop than traditionally developed parallel code. This is for a few reasons: generally, most teams won't take the time to parallelize all the parts of their code than can possibly be parallelized. Thus, they run into a sort of self imposed Amdahl's law situation--those parts that they haven't spent time parallelizing eventually become, relative to the entire app, the part of the app that takes longest to run. This problem is seen more with larger core counts, of course. Second, many highly talented engineers who are world class in their own domain are not also world class at writing multithreaded c++, and so may not have written their own multithreaded / numa aware memory allocator, or optimized the sse widths correctly for different chip generations and so on.
In the end of course, it depends on the algorithm, and delving into the paper, or even better, contacting them any trying it out with your particular algorithm, would provide the best answers.
4. I'm not aware not aware of other such languages/systems.
Just went through the paper (relevant sections only). Have gotten a some feel for what it is doing. Thanks so much.