For those of you still wondering what I'm talking about, I'll let you in on a little secret. We're showing the old design to about half of you, and the new design to the other half. Yes, this is intentional. We're collecting metrics to guage the effectiveness of the new design.

Would you like to do me a favor? Let me know what you think about it.  Does it work better than the old design?  How would you improve it?

We were motivated to do this because even though multi-core processors are everywhere, programs that make use of more than one processor are relatively rare. Granted, multi-threading is in common use within the high-performance computing community. They've used parallel processing for decades using techniques such as MPI for clusters and OpenMP for multi-processor systems. On the desktop, with the availability of "hyper-threading", or logical multi-processors, most of the commonly used pre-packaged software has also been adapted to use multiple processors. However, we have not yet reached the point where all programmers designing a new program or extension to some existing software ask themselves "how do I make my program use multiple processors if they are available and do the job in parallel?"

Writing a parallel program is far more complex than writing a sequential program. Until a person actually writes one, he/she will not appreciate the truth of the previous statement. There are any number of pitfalls and subtle issues when global state is modified simultaneously. But that complexity aside, there is also a lack of ease of access to parallel programming features in compiled languages such as C and C++. Yes, there are APIs provided by Microsoft Windows and standard threading packages such as pthreads, but they remain outside the language, harder to use than say, just writing a for-loop, and non-portable in general.

The language extensions we chose are a very small set: __parallel and __spawn for structured parallel execution in a fork-join model, a __par construct for for-loops whose iterations can be executed in parallel, and __critical for protecting against concurrent updates to shared variables.

We're eager to have you check out the compiler and tell us what you think. You opinion on the following would be very welcome:

1. are these extensions expressive enough to parallelize programs?
2. are they easy to use?
3. do they provide sufficient protection mechanisms against race conditions?
4. is it a good idea to build these features into the language?
5. do you see performance gains from using these features?

Other comments are also welcome.

Decimal arithmetic also provides a robust, reliable framework for financial applications that are often subject to legal requirements concerning rounding and precision of the results in the areas of banking, telephone billing, tax calculation, currency conversion, insurance, or accounting in general. The binary floating-point arithmetic that computers use does not always satisfy the existing accuracy requirements. For example, (7.00 / 10000.0) * 10000.0 calculated in single precision is 6.9999997504, and not 7.00. Similar examples can be found for double precision, or any other binary floating-point format. The underlying cause is that most decimal fractions, such as 0.1, cannot be represented exactly in binary floating-point format. The IEEE 754R standard proposal attempts to resolve such issues by defining all the rules for decimal floating-point arithmetic in a way that can be adopted and implemented on all computing systems in software, hardware, or a combination of the two.

In planning to improve on how decimal calculations are carried out and at the same time to make Intel Corporation one of the early adopters of the decimal floating-point arithmetic from the IEEE Standard 754R draft, we have implemented in software a decimal floating-point library, posted here. Standardization committees for high-level languages such as C and C++ are already developing plans to add decimal floating-point support to these languages. A software package such as this for decimal floating-point arithmetic can be used as a computation engine by compilers or other tools requiring decimal floating-point support, and it should constitute an attractive option for various financial computations. Our library has already been contributed to GCC 4.3, where it will be used for decimal floating-point calculations on Intel Architecture platforms.

• "I use Visual studio for native and Eclipse for java"
• "I would really like to be able to debug by going from JVM-code to Java-code and back"
• That would be more interesting if it would be more VM-independent
• "It is a bit scary to expect the jvm that you debub, be responsible for future debugging"
• "It would be interesting/fun to implement it in XXX as well"

Also I've chance to talk with author Mariot Chauvin of gdb-centric solution(see http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/cdt-home/presentations/spring2006/debugger_for_eclipse.ppt?cvsroot=Tools_Project

for details). He's mentioned about some instability of gdb/MI + Eclipse, and think that in VM debugging could add some stability.

Some my comment and thoughts.

First of all great thank to anonymous VM engineer and Mariot for interesting feedbacks and ideas. As for me I agree with instability GDB/MI, so why personally I prefer GDB/CLI. I agree with Mariot about "unmodified debugger"-centric solution, especially that the most modern VM doesn't use C-calling convention in jitted code and there should be some "extension" like CDB ("Microsoft Debugging Tools for Windows") has got to handle method entry/exit and JNI up(down)call to help debugger, mixing stacks and stack walking.

With NCAI we has the most issues resolved (java stack handling, jvmti safe points and other java world related things).

As usual, documentation of the product will provide detailed information about the product features. We also glad to advertise the latest issue of Intel Technology Journal which contains an article about the version 3.0 of Intel Performance Tuning Utility. The article is unique in the sense that it explains the motivation behind concepts that we put into the tool. It also takes a real-world example of tuning a multithread program and walks you through this process demonstrating how Intel PTU features are used. Reading the paper is a good chance to get prepared to the new tool version

Of course, I will make a separate post as soon as Intel® PTU 3.0 is uploaded to the WhatIf.

What engineers could expect from switching to single debugger scenario?

For developers single debugger scenario is a comfortable environment with unified style of management of key-binding, macro definitions, scripts and so on.

Is it only comfortable?

Observing debugger's usage models on http://www.systeminternals.com I see possibility to use debugger not only as developer tool but as a good playground for tools monitoring native and java worlds. While investigation current debugger solutions I've noticed some good prototypes from different sources:

1. HP (http://www.hp.com/products1/unix/java/pdfs/07_06Tools_NativeDebug.pdf) gdb-centric debugger.
2. Sun (http://docs.sun.com/source/819-3683/Java_debug.html) dbx-centric debugger.
3. Eclipse (http://eclipse-incub.svn.sourceforge.net/viewvc/eclipse-incub/jni_seamless_debugging/) gdb/CDT and JDT

All of them could be good foundation for debugger centric toolkits.

Dual nature debugger could be useful as developing and monitoring tool as well.

So why (jdb) JVMTI/JVMPI debugger is not in the list in-process debugger list? Basically in-process and out-process debugger is quite philosophical question measured with level of isolation. In java case we have managed and unmanaged code which are isolated with JVM[T|P]I layer.

Here I am in costume backstage. I'm dressed as a "Zombie Vampire Gorilla" - which is of course a mashed up Halloween costume.

Making my entrance.

Discussing monster mashups and explaining my costume.

Costume shed, and being more serious.

The New New Internet was a really fun event. Lots of fun stuff going on and some really great speakers.

(Sidebar: My wife thought it was really funny that we had a whole conference about "enabling", and suggested that I was now working with families and friends of those with addictions. No, not that kind of enabling, Deb.)

I was at SES 2007 to give a talk about OpenSolaris and help educate our enabling folks with what's available there. In the bargain, I decided to attend some of the other talks and learn about other useful technologies. One such talk I attended was on Transactional Memory or TM. Here are a couple of notes:

• Usually when you thread your code, you need to protect access to shared data between threads. These critical sections are usually by calling on a lock or mutex.
• The problem is that you often need to acquire a lock often when you don't need it – you are accessing memory which isn't shared between threads or you acquire locks for readers which are not required.
• The idea behind TM is to change the threading paradigm, and instead wrap your critical sections in code which marks it as TM.
• TM is based on the idea that most locks really are never contested, so a round trip to acquire and then release these uncontested locks are wasted. In other cases, you might only have readers accessing the data, and so you again, any locks acquired/released are wasted effort. Wouldn't it be nice to have the system automatically detect this, as if the memory itself was transactional in nature.
• To support this new threading model, the C/C++ language needs to be extended to add TM sections.
• Semantics proposed for TM sections in code.:
  • Area of the code is atomic relative to other threads which touch the shared data
  • Locks which are not needed are not acquired – instead, back out transactions if there is a conflict
  • Functions can be marked as tm_callable, which means that they will be backed out if there was a conflict
  • Tm_waveable allow you to show that you don't care about backing out a function call (like a debug printf)
• There is a prototype compiler implementing these semantics, and it's available in whatif.intel.com

I applaud the engineers working on this idea for trying to improve the lot of programmers who struggle to get their code threaded, performant and correct. I do have a few observations about this approach:

1. The biggest challenge with threading code is correctness – making sure that you have protected the right shared locations at the right times. It seems like this TM model doesn't materially affect this problem. If you forget to use locks around a critical section, won't you be likely to forget to put it in a TM section as well?
2. The other big challenge in threading is scalable performance – how do I decompose my problem to thread it in the first place? Do I do functional decomposition or data decomposition? Make the wrong choice, or pick the wrong level of granularity and your performance will not increase with added threads and it could slow down. Worse, if your code is moved to a system with more or less hardware threads available, the performance could change in undesirable ways. Unfortunately, again TM doesn't help you with this decision process. It might possibly mitigate some of the worst problems.
3. I'm often frustrated that our first implementation is with C/C++. I know that these are workhorse languages where performance matters, but it seems like Java or even Perl would be a good choice to impact more developers.
4. I can see some savings in avoiding unnecessary locks. In this case, I can see the opportunity in the performance area.

Check out the code at whatif.intel.com – maybe I am too pessimistic and this is the holy grail of threading.

http://thenewnewinternet.com/

Should be fun, particularly as I'm planning to give the talk in a gorilla suit (wondering why? You'll have to come see the talk).