STM Compiler

By Robert Geva (Intel) (1 posts) on September 16, 2007 at 9:09 pm

Hello, I'd like to welcome you to our STM portion of the whatif site.

As Intel is moving towards multi core processors, we are committed to provide development tools to help programmers exploit the parallelism available in these processors.

We view transactional memory as a part of the solution.

Here we offer a prototype implementation of our C/C++ compiler product with the addition of transactional programming constructs. (I will refer to it as a transactional compiler).

While a lot of work has been done in the area of transactional memory, we expect that yet more work is needed. Therefore, we are not providing a compiler with transactional programming as a product. Instead, we are making it available through our whatif site to encourage experimentations and to seek feedback on our choices.

The compiler available here is a result of collaboration between Intel's researchers and product teams. Practitioners in the area of transactional programming are well aware of the many contributions of Intel's researchers, and these are the researchers who participated in developing this compiler. Many professional programmers are also aware of Intel's development tools, the C/C++ compiler supporting OpenMP, Intel performance library and others. Members of this product team participated as well in the development of this compiler.

The current compiler provides the basic construct you would expect to express a transaction. Our syntax for a transaction is __tm_atomic[1] statement;'. Our implementation allows function calls within transactions. As we work in the IA32 eco system, we had two goals, that are particular to this domain: maintain the programmer's ability to control the size of the application, and allow them to leverage existing investments in IA32 SW packages. To that end, we provide facilities to express that a function will only be called within transactions, and alternatively to express that a function will be called both inside and outside of transactions. In the latter case, the compiler will generate two different translations of those functions. One that includes the transactional barriers for loads and stores, and one that does not. We also allow calling of functions that are not part of the current compilation and that were not compiled with transactional semantics. That allows a SW developer to use exciting packages where the source code is not available for recompilation. The addition to these constructs to the language made it harder to add some other constructs, mainly the "retry" and "abort" statements. While some would expect these to be a part of a transactional compiler, our initial view is that adding all of these constructs would results in a complex language. We therefore chose to not provide support for the retry and abort statements. We are seeking feedback on these, as well as some other choices.

Our goal in making available this early version of our transactional compiler is to encourage use of transactional programming and provide feedback on the usability of our language constructs. The implementation of these constructs was shown to provide acceptable performance on some programs we used internally. However, we do not expect it to perform consistently and we expect that some will see reduced performance when compared to other implementation alternatives. We chose to make the compiler available early rather than wait for a high performance implementation, which we hope to provide at a later time.

Thanks for your interest in our prototype compiler.

Robert Geva.

[1] We expect that once transactions are integrated into the C/C++ languages, the keywords will be friendlier. For the prototype implementation, our concern was to minimize the risk of name clashing with program variables.

Categories: What If Software

Comments (5) Comments RSS Feed

By Joseph Seigh on September 17th, 2007 at 2:20 am
I once did an STM implmentation in Java as an exercise to see what the api and implementation issues would be. Language issues were mainly Java closures and abstract pointer support being really really awkward. C++ has the same issues.

You can solve the issues by putting support in the compiler but this creates portability issues. Since STM is about scalability, you're talking about very large applications. At this point it would require a huge leap of faith and significant resources to port the application to STM even if portability wasn't an issue. Non portability makes it worse.

By Joe Crumm on September 17th, 2007 at 7:28 pm
Very interesting technology. Looking at your samples, I was wondering if the atomic blocks work with Windows/Linux threads or does one have to use OpenMP constructs for parallelism? (or do I have to learn OpenMP first to use it?)

jc

By Jim Cownie on September 18th, 2007 at 12:00 am
Joe, you can use the TM atomic blocks with any threading subsystem. We're using OpenMP just because it makes it easier to write small, portable pieces of code.

Good luck, please provide more feedback.

-- Jim

By Xinmin Tian on September 19th, 2007 at 11:57 am
The sample code #3 we posted uses the POSIX threads and __tm_atomic on Linux platform.

-Xinmin

By Joe Crumm on September 19th, 2007 at 1:42 pm
Xinmin: Yes indeed, I somehow missed the third sample.

jc


What do you think?

Name (required)

Email (required; will not be displayed on this page)

Your URL (optional)

Comments (required)