The Chinese Solar Machine Layer by Layer Fire in the Library The Mystery Behind Anesthesia
Marc Rosenthal
We need languages that take full advantage of multicore processing.
The evolution of computer programming has been largely independent of actual computer evolution. Languages such as C++ have lived through many generations of computers, and although they've surely been influenced by changes in technology, most modifications of them have been attempts to meet the needs of people, not computers.
Computer evolution, however, is now headed down an entirely new path: instead of simply becoming faster, our computer processors are being conjoined to work together. That new computer architecture requires a serious evolution in computer programming. Without it, we can only scratch the surface of what multicore computing can really do (see "Parallel Universe").
It's a change that will not come easily. The last great shift in computer programming was object orientation. This didn't just represent a new language or syntax; it represented a new way of thinking about programming, a new way of visualizing programs even before the first line of code was written. Some programmers simply could not make the leap. Whether their minds were too stuck on procedural development or the concepts themselves were too abstract, they couldn't adjust what they knew.
Programming for multicore technology is again not just a fantastic leap in programming, but a leap in conceiving and understanding programs. Historically, programming could be described as giving instructions to a computer on how to act upon some public data; the easier it was to get to the data, the faster and easier coding would be. The principle is similar for multicore programming, except that you must consider that others may be acting on the data at the same time. Programmers must now take into account that someone else might be simultaneously sharing the data their code will work on.
One reason this problem has proved difficult is our insistence on shoehorning old languages into the new paradigm. Languages such as Java and C++ are being patched or updated to try to keep up, but programs written in them require careful coding when run on multicore chips. The good news is that new languages--built with the idea that shared data can and will change without notice--are better suited to this new paradigm. Part of their success lies in the fact that they are designed to keep data unshared until the programmer explicitly says otherwise.
With these new languages and programmers' development of new skills, the acceleration of computing power that we've almost come to take for granted will soon be back on track.
Paul Tyma is the CTO of Home-Account, an analytics startup focusing on the mortgage industry. Previously he was a senior engineer in Google's multicore team.
why most apps are not yet multicore-enabled
Multicore is here, yet the vast majority of applications have not been multicore-enabled. Why? Well, first of all, parallel programming is hard — in fact viewed by many as an unsolved problem. And second, here’s the rough calculus done today by software development teams: On a dual-core system (the typical configuration today), one can typically expect a two-fold improvement at best. This performance improvement is just not compelling enough to make the (potentially considerable) development investment. Once the 8- and 16-core systems become mainstream, however, a single-threaded application may be leaving an order of magnitude in performance and throughput on the table. That’s when multicore enablement moves from "nice to have" to a "must have."
We at Cilk Arts - along with Intel, Microsoft, and the OpenMP effort - are working to deliver a programming methodology that'll work well for multicore CPUs. Cilk Arts
We have languages for describing parallelism already - the ones we use for hardware design. Here's what you get if you add the same functionality to C++ -
http://parallel.cc
Manufacturing in the United States is in trouble. That's bad news not just for the country's economy but for the future of innovation.
This document is part of the “How-To Guide for Most Common Measurements” centralized resource portal. This tutorial provides a detailed guide for measurement and device considerations to take temperature measurements using thermocouples. Get an introduction to thermocouples, which are inexpensive sensing devices widely used with PC-based data acquisition systems. Also review some specific thermocouple examples and learn how thermocouples work and ways to integrate them into a data acquisition measurement system.
View full PDF >Our list of the 50 most innovative companies, including the following:
Mapou
357 Comments
How to Solve the Parallel Programming Crisis
It's always good to read articles that keep reminding us of the parallel programming crisis. Unless a solution is found soon, it is a crisis that is going to be felt far and wide and cost the industry billions of dollars. The problem is not the lack of development tools, in my opinion. We have plenty of tools that can handle multithreading. The problem is that threads are, by their very nature, non-deterministic. This is a mortal sin in engineering and no tool is going to get around that simple fact.
The solution to the parallel programming crisis is to do away with threads altogether. There is a way to design and program computers that does not require the use of threads at all. It is based on a method that has been around for decades. It is not rocket science, but unless the industry is willing to abandon the failing and failed paradigms of the last century, I'm afraid there will be a very heavy price to pay. To find out how to solve the parallel programming crisis, click on the following link.
http://rebelscience.blogspot.com/2008/07/how-to-solve-parallel-programming.html
Reply