Software Development

In short, statements like the one in the article are really strange to me. It does display something way more important though. That at one point, developers will have to make a choice. They can stick with what they're using now, or they can move on to a different kind of development that will handle concurrency automatically. The second option will be something they will likely hate, at least at first, simply because it's different and will be unwieldy for them until they get the hang of it. I had a high learning curve to go through and I'm the one creating this stuff. So I'm realistic to the idea that there will be a lot of reluctance by experienced programmers. This is why I've always claimed that regular users (non-programmers) and elite programmers will be the ones who will show the least resistance. These will be the people with nothing to lose.

Does your experience in compilers give you a different perspective than the average developer?

It probably does. I’ve been working in compilers for more than 10 years, so I know how hard some of the problems are, but I can also imagine new analytical tools and language features that would make concurrency easier.

The key point here is easier. I think he's still talking about current ways of programming. That's really odd. We already know their limitations. Yet the push is still in the same direction even though he sees "Wrong Way" signs all over the place.

Concurrency needs to be well supported throughout the whole software ecosystem: languages, tools, libraries and legacy code.

I don't think this is an absolute. In fact, it shows exactly why he doesn't see any solutions. He just keeps going down the same road. Dare to look in a new direction! Like I said, there's not much substance in that article.

Then I saw this blog entry titled Shared Mutable Memory Must Die. This is again looking at the problem from current methods of programming. It really misses the ball on a lot of things. Sure, shared memory does have some issues, but it is workable. The real problem I have is where one cache is shared amongst processing cores. But if there were overlapping caches, I'd really like that. That would rock. What I mean is this. Suppose you have a 16 core machine. Now take 4 groups of 4 cores. Each group would have a shared cache that all 4 cores could use. Then you take one core out of each group and create a higher level group of 4 cores. These would likewise have shared cache. In this way, it would be possible to create concurrent software that would never go to RAM in order to communicate between nodes.

That all cores have access to RAM isn't so bad. The only problem I see is if ALL cores share the same cache. That's a problem because one core can really screw up the cache for other cores. That's the only problem I can see. Anything else and it's fine. Personally, I would like to see things like inter-core DMA channels.

The article in question keeps talking about locks and how it'll slow things down and makes things extremely difficult. Only if you lock every single data access. A better scheme would be if all cores had a shared counter. It doesn't matter what speed it goes just as long as it's the exact same counter. Then you can make sure that your locks are never written at the same time. And you can do this relatively easy. Also, you can group locks together so as not to slow things down. Really, this isn't a problem. It's only a problem if you use old style threads and the author of that blog entry can't shake that notion.

Transferring messages via RAM is slow. I'll give him that. But that's a problem in any concurrent architecture. Give it time. Hardware will always adapt to what developers use. They want software to run faster. But right now, people use old-school threading and concurrency. As long as that exists, hardware has no reason to change. They'll try a few different things to be sure... until something grabs hold. Until then, developers have to lead the way if they want something different.

I'll just mention one thing to look out for in any kind of article that speaks about concurrency. Look if they talk about handling concurrency automatically. If not, the article is automatically useless. If they start talking about legacy applications or that it's impossible or that they don't even look at how this could be done, then you can know that the rest of the article is a dead end. The simple reason is that you can't have something new by using the old. If you try to do that, it's a lost cause.