Core language strategy

David Stewart, in his recent post on "Core software strategy", advised on selecting the core software suitable for your application, and it is right on. I am going to build on that and address the issue of "Core programming language strategy", since that is what programmers directly think in and write in.


What is the current environment? Most of our AEs (Applications engineers) are involved with further speeding up applications that are already straining the limits of our processors. (I forgot to mention in this series what AEs do - something that I should have done in the first post). AEs work with software vendors helping them to improve their software to run better on every generation of processors. So performance is central to what they do, and they prefer a language that lets them push the pedal to the metal. Some of the other technologies that come with our new processors- like mobility, manageability, security, etc. - require a different type of enabling; not so much to do with performance, but with quick incorporation of these technologies into the application. The demands here are more on the productivity of programmers and in turn, on the expressiveness of the language they are coding in.


However, productivity and performance have not gone well together. If you use a highly productive language (say, Ruby), you should be prepared for a major hit on performance and vice versa.


To cater to both these demands, you could choose a mixed language strategy of choosing appropriate languages suitable for the performance-critical sections and the rapid development sections, and linking them together, or you can just select a "core language".


In a recent project, I had the opportunity to use managed C++ in a sizeable program and it was quick to develop. As the project was ending, the new C++ in Microsoft* Visual studio 2005 was released and I then studied it (along with the marketing material included in it). With the tighter integration with .NET built in, it appeared that it addressed both the productivity and performance issues very well. Since it is a common dilemma for AEs, I requested a session to talk about it in the Software enabling summit and it was granted. So I gave this session titled "C++/CLI in Visual studio 2005", in this, I was showing a simple code sample on navigating an XmlDocument in C++, when one of the audience members asked "Is this a C# example you are showing?" I replied that it was C++, and moved on with the presentation. It occurred to me much later, on introspection, that the questioner had mistaken the code for C#, because he saw how easily the .NET classes were used from C++. I wish I had pointed that out right in the class, since that was the purpose of the class.


Anyway, it looks to me that C++ with VS 2005 continues to be a viable core language for the high-end applications today. Many of these performance-critical applications are in C++ already anyway, though sometimes just for historical reasons.


I am sure the Java and the C# people will have an earful to say on this. I would like to see some comparative data on the performance of languages. Please add a comment with the link, if you know of such data posted somewhere.


(The above statements are my personal opinion and do not reflect my employer Intel Corp.'s position on these matters; all trademarks belong to the respective owners.)
Regards,
KS



Для получения подробной информации о возможностях оптимизации компилятора обратитесь к нашему Уведомлению об оптимизации.