3 ms·

I very much agree with you. Another interesting observation is that, on cache-coherent systems, the maximum possible clock rate also tends to go down as soon a

by dom0 10y ago

I very much agree with you. Another interesting observation is that, on cache-coherent systems, the maximum possible clock rate also tends to go down as soon as more than one socket is used. > (which are the easy gimmie for slow-and-wide designs) Nowadays they are more of an historical anecdote, but some time ago Sun created the "niagara" line of barrel processors - a technique that is a form of simultaneous multi-threading, like Hyper-Threading, just with 8-16 threads / core. These UltraSparc T1, T2, ... processors held quite some throughput benchmarks - but were obviously not feasible and not meant for general purpose use.

paulmd 10y ago
> Another interesting observation is that, on cache-coherent systems, the maximum possible clock rate also tends to go down as soon as more than one socket is used. Which is perfectly sensible if you think about it. No matter how fast your cache coherence mechanism is, it's slower than not sharing cache between two chips. It's fine if you are storing program code or independent data, but if you are operating on the same cache lines as another processor you have to flush the dirty lines over and possibly roll back a whole bunch of execution that might have been done there. Sometimes this even happens when the data you are working on is different but shares a cache line (false sharing). > Nowadays they are more of an historical anecdote, but some time ago Sun created the "niagara" line of barrel processors - a technique that is a form of simultaneous multi-threading, like Hyper-Threading, just with 8-16 threads / core. We do a lot of contracting with a state government and I'm pretty sure they're still running these in their datacenter. It's some flavor of SPARC for sure, and I was talking to our sysadmin and he mentioned that they used a processor that I remember was a lot wider than hyperthreading, which sounds a lot like UltraSPARC. From what my guy explained they are pretty nice in database workloads especially since they're also an Oracle DB shop. They are locked into Oracle products seriously hard and they're unwilling to contemplate moving to commodity products. Probably unable to, given their staff's skillset and in-house operating procedures. It shouldn't take a tiger team for someone to suggest restarting a misbehaving server. You get what you pay for though. The state doesn't pay much and people who have other options don't stay in that kind of work environment.

by dom0 10y ago

paulmd 10y ago

> Another interesting observation is that, on cache-coherent systems, the maximum possible clock rate also tends to go down as soon as more than one socket is used. Which is perfectly sensible if you think about it. No matter how fast your cache coherence mechanism is, it's slower than not sharing cache between two chips. It's fine if you are storing program code or independent data, but if you are operating on the same cache lines as another processor you have to flush the dirty lines over and possibly roll back a whole bunch of execution that might have been done there. Sometimes this even happens when the data you are working on is different but shares a cache line (false sharing). > Nowadays they are more of an historical anecdote, but some time ago Sun created the "niagara" line of barrel processors - a technique that is a form of simultaneous multi-threading, like Hyper-Threading, just with 8-16 threads / core. We do a lot of contracting with a state government and I'm pretty sure they're still running these in their datacenter. It's some flavor of SPARC for sure, and I was talking to our sysadmin and he mentioned that they used a processor that I remember was a lot wider than hyperthreading, which sounds a lot like UltraSPARC. From what my guy explained they are pretty nice in database workloads especially since they're also an Oracle DB shop. They are locked into Oracle products seriously hard and they're unwilling to contemplate moving to commodity products. Probably unable to, given their staff's skillset and in-house operating procedures. It shouldn't take a tiger team for someone to suggest restarting a misbehaving server. You get what you pay for though. The state doesn't pay much and people who have other options don't stay in that kind of work environment.