Trends in Multithreaded processing

[Voo]

Actually that's rather OT, considering that the thread title is about "Trends in Multithreaded processing", so we could also discuss some new ideas for cache coherency and co, since I think we all agree that the current ones won't scale very well to dozens or even hundreds of cores.

Imho a bit more interesting than the nth CISC vs. RISC discussion

PS: And while I'm way too young to have actively programmed a PDP11 or anything, I've had some CA lectures and I must say, the PDP11 CISC style is rather interesting to write in:
Something like that:
foo: mov (r5)+, r0
add (r5)+, r0
rts r5
...
jsr r5, foo
.word #40
.word #2
;next instr

 

[degibson]

Actually that's rather OT, considering that the thread title is about "Trends in Multithreaded processing", so we could also discuss some new ideas for cache coherency and co, since I think we all agree that the current ones won't scale very well to dozens or even hundreds of cores.

x2 /agree's on this. This thread is taking on a life of its own. Just to derail even further... I did just read a decent paper on cache coherence, now that you bring it up:

Fractal Coherence
www.ee.duke.edu/~sorin/papers/micro10_fractal.pdf

Idea: Verify system for small number of nodes. Show that a collection of a small number of nodes acts like a small number of nodes. Ergo, coherence works for a large number of nodes.

Not exactly performance scaling, admittedly, but interesting.

 

[Scali]

PS: And while I'm way too young to have actively programmed a PDP11 or anything, I've had some CA lectures and I must say, the PDP11 CISC style is rather interesting to write in

If you put 68k alongside it, you'll see a lot of similarities.
Which also shows where microprocessors came from. They mainly borrowed from mainframe/minicomputer technology. Microprocessors such as the x86 and 68k weren't exactly at the cutting-edge of hardware and software development back in those days.
And when microprocessors became common in mainframes and such, they weren't x86 or 68k either, but rather the 'big guys' such as HP's PA-RISC, DEC's Alpha, IBM's POWER.

But these days the PC market is so large that it makes more sense to invest everything in PC components such as x86 processors and GPUs, and then scale it up to supercomputers.

 

[Cerb]

Actually that's rather OT, considering that the thread title is about "Trends in Multithreaded processing", so we could also discuss some new ideas for cache coherency and co, since I think we all agree that the current ones won't scale very well to dozens or even hundreds of cores.

If done in software, such that the program used separate pages for each thread, then software checks and merges; would you be able to keep HW CC, as a fall-back, yet not be limited by its performance amongst many cores?

 

[degibson]

If done in software, such that the program used separate pages for each thread, then software checks and merges; would you be able to keep HW CC, as a fall-back, yet not be limited by its performance amongst many cores?

Maybe. But it's not clear that software can do it faster, given that degree of scaling. E.g., current suggested on-chip topologies won't offer the cross-sectional bandwidth needed to implement page merging, because of performance interference from other cores. This is going to be a really interesting problem overall, and I look forward to seeing the proposed solutions.

 

[Voo]

Idea: Verify system for small number of nodes. Show that a collection of a small number of nodes acts like a small number of nodes. Ergo, coherence works for a large number of nodes.

Not exactly performance scaling, admittedly, but interesting.

Should read that in detail someday, sounds interesting. Especially considering that some cc protocolls are really, really complicated (IBM especially) - wouldn't want to
verify those. And with the extra problems we're facing a sound footing can't harm. Like the old saying in SW: It's easier to optimize correct code than to correct optimized code

@Cerb: Could be a scaling problem and the overhead for memory barriers could be rather large. I think for basic, but extremely performance critical things like a cache protocoll a HW solution should be prefered.

 

[Martimus]

The ones that matter most, aren't shared: the schedulers and integer units (as I already said, so what's the point of your entire post?).
They're saving on die area more than they are improving execution efficiency.
And saving on die-area is not as spectacular as the 'savings' with HT (I say 'savings', because it's more like you get a 'free' extra core with only a handful of logic, so it makes much more sense to look at it from the nr of physical cores than the other way around).

You are looking at this completely bass-ackwards. The HT solution was always about maximizing the current available resources. The Bulldozer soultion is about maximizing the possible throughput using the fewest resources. I am trying to show how this is going about, but you continue to push it back to maximization of current resources, which was never the goal.

The Schedulers and Integer units are not shared, because they are used more than any other portion of the chip. Sharing these resources causes mroe thrashing of threads, and creates a bigger bottleneck for thread throughput than just about any other portion of the chip. It makes far more sense to seperate this portion than any other portion. I still don't understand why you feel this isn't the case.

I have been wondering this for a long time, but would you care to let me know why you have a personal hatred toward AMD? I never have seen you write your reasoning. I don't understand it, but I don't know the whole story, so I would appreciate it if you enlightened me. It would make it easier to understand where you are coming from.

 

[Scali]

I have been wondering this for a long time, but would you care to let me know why you have a personal hatred toward AMD? I never have seen you write your reasoning. I don't understand it, but I don't know the whole story, so I would appreciate it if you enlightened me. It would make it easier to understand where you are coming from.

I don't like such questions.
Should you hate one company if you happen to prefer the approach of another company at any given time?
Do you have a personal hatred toward Intel?
I don't understand your reasoning, and I don't think I want to know.

Once Bulldozer is out, we'll see if my estimates were correct.

 

[Martimus]

I don't like such questions.
Should you hate one company if you happen to prefer the approach of another company at any given time?
Do you have a personal hatred toward Intel?
I don't understand your reasoning, and I don't think I want to know.

Once Bulldozer is out, we'll see if my estimates were correct.

I don't hate Intel. I was bothered with their business practices in the 90's and early 2000's, but I don't have any personal issues with the company.

I am glad to see that I was wrong about your feelings about AMD. I made the assumption based on your history of posts, and your zeal for the information you try to convey. I am actually glad I asked the question, because it will make me feel a little better about future conversations with you.

(I actually avoided even reading this thread I started for weeks just because I didn't want to get into a long argument with you. I have grown to hate arguments, even though I loved to argue when I was younger, and my instinct is to fight when confronted. This instinct is the reason I avoid situations where I feel a fight may occur. I don't enjoy fighting, and I feel horrible afterward when I do fight.)

 

[Scali]

I made the assumption based on your history of posts, and your zeal for the information you try to convey.

I think that has more to do with the AMD camp, and how they constantly make personal attacks, and try to put you in a certain corner.
You were actually doing exactly the same with your question just now.
If you just would stop doing that, we could have a normal discussion about current and future technology. But sadly, too many people have some kind of hangup about hardware companies, and want to defend 'their' brand at all cost, while not really being interested in a technical discussion.
Attacking someone personally is what you do when you don't have any technical arguments.