 | |||
|
|
||
| |||
| |||
| |||
|
||||||||||||||||||||
| |
|
Home > Microsoft .Net Development News > .NET Framework goes multicore |
| |
|
|
|
|
| Microsoft .Net Development News: |
|
||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|
|||||||||||||||||||||||||||||||||||||||||||
Extensions to the .NET Framework 3.5 are a first draft at history. This CTP begins to tap into the power of multiprocessor chips, while letting developers work with the familiar .NET paradigm. Many viewers have suggested that the next generation of multicore processors will require changes in application development, which these new extensions seem to augur. Even people with hot rod hearts hardly lift the lid on their engines anymore. There is not much in the modern car on which they can work. The same has become true in software engineering. Lately, developers have not needed to be acutely aware of the inner workings of their "engines." As high-level languages and faster chips came into play, many application developers got away from working to wring optimal performance out of the microprocessor. Things may be about to change -- somewhat. Viewers have suggested that the next generation of chips with multiple processors will require changes in application development in order to obtain performance improvements. These changes may come in stages and may mean different things to developers working in different languages. Late last year, just after Visual Studio 2008 was formally released, Microsoft offered preview software that shows where things may be headed in terms of support for parallelism in future versions of .NET and Visual Studio. Soma Somasegar, corporate vice president in Microsoft's Developer Division announced the Parallel Extensions Community Technology Preview (CTP) that runs on the .NET Framework 3.5, thus tapping into features in C# 3.0 and Visual Basic 2008. Parallelism APIs in the new .NET extensions support parallel For and ForEach loops. Declarative data parallelism is supported in the form of a data parallel implementation of LINQ-to-Objects that eases implementation of LINQ queries that run on multiple processors. Meanwhile a new concurrency runtime maps and balances code "to available concurrent resources on the execution platform." Much of the multicore software activity to date could be described as language-centric. While Microsoft addresses .NET language needs with the .NET Parallel Extensions, there are alternatives for other languages. C, C++ and Fortran developers' needs to adjust to multicores may be handled by the OpenMP shared memory API, or, in the case of C++ developers, multicore needs may be met by Intel's Threading Building Blocks Library. So far, it may be the case that Java developers find the bulk of their requirements are met with the threading support already part of the language. Some folks -- Fortran, C and C++ supercomputer programmers -- have been doing parallel programming for quite a while, noted James Reinders, chief product evangelist for Intel's Software Development Products Division. This is a select bunch. But in the future, he said, "every programmer is going to have the opportunity to understand parallelism by doing some explicit things." A deep immersion may not be required for all, though. "Parallelism will definitely speed up parts of programs more than others," Reinders said. Still, it may be good if application developers do not have to learn too much, so long as a level of abstraction can be maintained, above the 'guts' of the processor.NET extensions, he indicated. Understanding where parallelism can be effectively applied to existing programs will be important. What are Reinders's thoughts on the .NET Parallel Extensions? "I think it's an important step," he said. Getting out early, even in a partial form, is good. "We are definitely unsure as an industry exactly how people will use this, and what they will need," he said. "I think it is important to put some solution out there [supporting abstraction] and to see what is next." Reinders said computationally intensive applications will be good first program targets, but that many other applications can benefit from parallelism, if developers can discern which portions of the portions of their apps meet the appropriate criteria. The focus for now will be on computationally intensive programs, said Jeffrey Richter, instructor, consultant and co-founder, Wintellect, discussing Parallel Extensions to .NET. With the increasingly wide use of multimedia, these types of programs may cover a wider arena than they have in the past. "This is for computationally bound programs," said Richter, citing financial analysis, engineering analysis, video and audio signal processing, and "transcoding between file formats" as examples. Richter has been involved with creating similar utilities for concurrency for a long time. "I have my own Power Threading Library that has similar features (to the Parallel Extensions to .NET). I understand what they are trying to do. They are focusing on computationally bound problems. That is where the library becomes useful to you." He cautioned that developers should be sure they need parallelism before adopting such extensions. "If you don't really need it, it will even slow you down," he said. The new For and ForEach commands are interesting, said Ben Day, consultant and blogger at BenDay.com "Being able to use a special syntax to parallelize For and ForEach operations is a great place to start," Day said. "This is some exciting news especially since most new hardware is multi-core or multi-processor." "What we didn't have -- and what these extensions will give us -- is an easy way for .NET developers to use multithreading in their code, hopefully without giving us meters of rope to hang ourselves with." "Ideally, the new extensions hook into some multi-threaded code in the .NET framework and that will be what hooks into the multi-threaded/multi-core/multi-processor features of the OS," said Day, who is a Microsft MVP for C#. Intel evangelist Reinders said that, when he goes out to talk with programmers on parallelism, much of the time is spent talking with them until they come to grips with what kind of parallelism their program may already have within it. "For programmers trained to think sequentially, step by step, the big challenge is deciding what they should do in parallel." Abstraction, meanwhile is important. One could be hard pressed in the future, if they code to directly to a quad-core processor. There will, he advises, be multicores beyond quad cores in the future.
|
|
|
|
|||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||
|
|
About Us | Contact Us | For Advertisers | For Business Partners | Site Index | RSS |
|
|
||
|
|||||||
