C Is Not a Low-level Language

I think the article is misleading, especially its title. It's not about C language per se.
The actual question is about "serial" and "parallel" programs: most likely it is true that the modern processors are designed to perform better by executing parallel tasks. Imagine if you run just a regular single-threaded C program: why you would need all those multi-core hyper-threaded CPU with complex pipelines etc?
 
It's not? :rolleyes:
My first instinct from the title was that it was an attention grabbing headline. My second thought, before reading it, is in comparison to machine language.
 
The actual question is about "serial" and "parallel" programs: most likely it is true that the modern processors are designed to perform better by executing parallel tasks. Imagine if you run just a regular single-threaded C program: why you would need all those multi-core hyper-threaded CPU with complex pipelines etc?
Because, something that is more logically tuned to the hardware would be able to do any process more efficiently based on the hardware's specifications.
 
"that's just another way of saying that C doesn't map to modern hardware very well"

Is there any language out there that does? Or is it perhaps that the human approach to programming doesn't map to modern hardware very well?

I found that C is pretty awkward (and more importantly, unsafe) when it comes to writing parallel code. But after looking at other languages, nothing really has a better solution. At least with the popularity of C we have a shed-load of debugging tools for parallel code. In the article it mentioned Erlang. Isn't that a garbage collected Java JVM frontend? I cannot see how that can map to hardware any better. Sure, it might apparently make dealing with lots of threads pretty easy but interacting with the hardware (i.e for an OS) is not entirely possible in pure JVM (thats why JVM was itself written in C/C++).

Perhaps if we cannot correctly "wrangle" parallel programming, we should give up and look for another way to make processors faster. Perhaps this whole parallel thing is Intel's design plateauing.
 
Some interesting reading, thank you very much. It is certainly necessary to see what the future brings. Once upon a time I tipped my fingers into adaptive hardware, looks like it is time to get going again.
 
I found that C is pretty awkward (and more importantly, unsafe) when it comes to writing parallel code.

C and C++ do not naturally have a way to express parallelism, nor to express locking to force serialization where parallelism is harmful. It is very easy to add locking to C/C++ code, and there is more than one way to do it. But all these ways require care and discipline, and good training of all software developers.

At least with the popularity of C we have a shed-load of debugging tools for parallel code.

Similar things exist for other languages too, definitely Java and Python. A while ago (perhaps a year), a Python program I had written for fun at home (roughly 12KLOC) kept deadlocking on me. Which is embarrassing, because I do this kind of stuff professionally, so stupid mistakes like that shouldn't happen. So I looked around a bit, and within half an hour I had tracing, debugging and deadlock detection tools downloaded, and the problem found. It was really dumb; that's what happens when you think a problem is easy and you write code for it in the evening after dinner.

... Isn't that a garbage collected Java JVM frontend? I cannot see how that can map to hardware any better.

Having a programming language that exactly exposes the hardware does not imply that it is the only efficient way of using the hardware. Expressing your program in a higher-level language (in the style of the bytecode that go into a JVM) can actually give the execution engine more semantic hints for running it efficiently, by mapping larger concepts onto the facilities that the hardware happens to provide, without each engineer having to deal with the low-level stuff all the time.

Sure, it might apparently make dealing with lots of threads pretty easy but interacting with the hardware (i.e for an OS) is not entirely possible in pure JVM (thats why JVM was itself written in C/C++).

In the late 90s and early 00s we had various Java CPU and Java OS, which all executed Java natively. That turned out to be a really dumb idea, and a great waste of money. But amusing.

Perhaps if we cannot correctly "wrangle" parallel programming, we should give up and look for another way to make processors faster. Perhaps this whole parallel thing is Intel's design plateauing.

Sadly, given the unfortunate real-world limitations of chip design and power consumption, CPUs will get more massively parallel as time goes on: more cores, more parallel execution within cores. Right now, I don't see a way out of that. This means that we all need to get better at efficiently and correctly expressing our programs in a way that can be executed on the hardware we'll have.
 
Perhaps this whole parallel thing is Intel's design plateauing.
And you'd be right. You need a number of atoms to make a component in an IC and they can't get closer than a minimum number of atoms per component. They are reaching that point and, thus, the need for more parallel operations.
 
In the late 90s and early 00s we had various Java CPU and Java OS, which all executed Java natively. That turned out to be a really dumb idea, and a great waste of money. But amusing.
I love that. I remember those, too.
This means that we all need to get better at efficiently and correctly expressing our programs in a way that can be executed on the hardware we'll have.
Instead of scrambling around trying to find a library/framework/plugin/someone-else's-code-so-we-don't-have-to-think-for-ourselves. I think they call that software engineering. Or maybe programming.

I've been preaching that to the web masses for years but consider the audience.
 
Back
Top