

SequenceL: A very simple parallel programming language - alok-g
http://en.wikipedia.org/wiki/SequenceL

======
dsheth
I'm not the submitter, but I work with the people who write sequenceL and can
answer questions about it.

~~~
alok-g
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/>

~~~
dsheth
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...](http://www.texasmulticoretechnologies.com/content/2004_SL_Transparency_and_Multicore_Parallelisms.pdf)

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.

~~~
alok-g
Just went through the paper (relevant sections only). Have gotten a some feel
for what it is doing. Thanks so much.

