Oracle Demos New SPARC T4 Processor

Single thread performance by toQDuj · 2011-09-27 00:55 · Score: 1

"Oracle claims the chip's single-threaded performance has been significantly boosted"
Be that as it may, the TX chips were designed to handle a vast multitude of threads with lower performance per thread. So now they are trying to turn that design around? Seems to me they are designing the processor equivalent of the half-track.

--
Every experiment which ends in a big bang is a good experiment.

Re:Single thread performance by lanc · 2011-09-27 01:04 · Score: 1

Well, it is still 64 threads per socket, or 256 threads per box that that run parallelly. Is that not vast enough? With the 5x signlethread performance compared to the T3?

--
"First they ignore you, then they laugh at you, then they attack you, then you win." -- Mahatma Gandhi
Re:Single thread performance by MetalliQaZ · 2011-09-27 01:31 · Score: 4, Interesting

This comment may have been meant as a bite at Oracle, but it is really a good point. The T4 may be a departure, but that doesn't mean it isn't warranted. The chip is still massively parallel, but it has obviously been refocused. The question is, what does the application need? Perhaps the engineers saw the biggest gains for DB applications in boosting single thread performance. MySQL probably will benefit from the same things that benefit Oracle DB. What are the customer demands for power consumption? Are the tradeoffs balanced? Perhaps lower-power chips require too many servers to store and cool. The T4 still looks like a mighty processor.
Still, if they venture too far into Intel's Xeon space, they will have a hard fight indeed.
-d

--
"Here Lies Philip J. Fry, named for his uncle, to carry on his spirit"
Re:Single thread performance by spiffmastercow · 2011-09-27 01:32 · Score: 1

Well, it is still 64 threads per socket, or 256 threads per box that that run parallelly. Is that not vast enough? With the 5x signlethread performance compared to the T3?
It may be "vast" enough, but given that 4-8 cores is the most that will typically get used, it may not be *fast* enough, and may be a big waste.
Re:Single thread performance by V!NCENT · 2011-09-27 01:32 · Score: 1

A lot of CPUs in one CPU with low power consumption sounds nice, but that sounds a lot like a GPU setup to me.
Given that GPGPUs are taking over, I smell that they are in need for another problem. My guess is that this powerhouse is seriously going to kick Intel in the balls with Intels failing demonstrations of realtime raytracing.
So where can I get my hands on a Sparc workstation? >:-)

--
Here be signatures
Re:Single thread performance by Vectormatic · 2011-09-27 01:39 · Score: 1

If you are only using 4-8 cores at a time, you are clearly not the target audience for these chips.

--
People, what a bunch of bastards
Re:Single thread performance by FreakyGreenLeaky · 2011-09-27 02:13 · Score: 2

but given that 4-8 cores is the most that will typically get used
You clearly don't understand the target market of these chips. In fact, your statement is hilariously ignorant.
Re:Single thread performance by owlstead · 2011-09-27 02:16 · Score: 1

This is very much a generic CPU, nothing to do with vector processing. It's main tarket is enterprise & communication application servers. Hence the crypto-units and networking capabilities build in. A GPU might well outrun it regarding vector processing though.
Re:Single thread performance by Anonymous Coward · 2011-09-27 02:16 · Score: 1

Actually, they may be - by definition, when a single thread (one out of 8) gets boosted to the high performance mode, it's one per core - so up to 8 *single threaded* applications could be boosted to high performance. Doing this with a single socket is very cool, being able to do this on a per-core basis is even cooler.
given some software company's inability to write efficient multi-threaded code, it gives as close as you can get to the best of both worlds. Some cores doing high perf single thread, others doing many threads per core (java code, etc).
Re:Single thread performance by segedunum · 2011-09-27 02:39 · Score: 1

The point that the OP was making was that the target market for these chips is terribly small. The big market is for ever bigger single tasks and threads to be completed in less and less time. The fact that they've had to come up with this halfway-house tells you that this is unlikely to save SPARC as a platform.
Re:Single thread performance by TheRaven64 · 2011-09-27 02:54 · Score: 1

Unless you happen to have a massively parallel application that needs to serve a huge number of concurrent users. Like, say, a database. Or a web app.

--
I am TheRaven on Soylent News
Re:Single thread performance by Anonymous Coward · 2011-09-27 02:55 · Score: 1

Terribly small? Most any business who currently uses SPARC would be a target market for these systems. If you consider that small, then I guess we have different opinions on the definition.
The T4 merges the strengths of the T-Series and M-Series together. Looks good to me.
Re:Single thread performance by ThePhilips · 2011-09-27 02:56 · Score: 1

Am I missing something?
Has Sun produced any non-Tn CPU after UltraSPARC IV+ in 2005?
I haven't heard anything about UltraSPARC V - only the T line.
P.S. But probably I shouldn't care anymore. My company recently has just changed the "strategic platform" from Solaris 10 to RHL6.

--
All hope abandon ye who enter here.
Re:Single thread performance by spiffmastercow · 2011-09-27 03:15 · Score: 1

Unless you happen to have a massively parallel application that needs to serve a huge number of concurrent users. Like, say, a database. Or a web app.
In almost any relational database your bottleneck is going to be storage -- you might be able to process things 32 times as fast, but you're still going to have to wait for that save op to complete before doing anything else. As for web apps, well.. it depends.
Re:Single thread performance by Bengie · 2011-09-27 04:06 · Score: 1

The T3 has a shared FPU among all those cores. The FP performance is horrible, but it can crank out the int performance required for an efficient web/db server.
Don't expect Ray Tracing with an INT heavy CPU.
Re:Single thread performance by Bengie · 2011-09-27 05:10 · Score: 2

A heavy read database, like a news site, will have nearly everything cached in memory.
I've done ad-hoc aggregate functions against non-indexed tables with over 100mil rows, and they return in sub 10ms times. Cached table data can be fast.
Re:Single thread performance by afidel · 2011-09-27 06:21 · Score: 1

The more interesting question is will 256 threads per box be enough to compete with 160 threads per box from Intel (8x 10 core Xeon's with hyperthreading) or the monster boxes from IBM, or heck even the 512 thread M9000 they get from Fujitsu.

--
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
Re:Single thread performance by swordgeek · 2011-09-27 06:34 · Score: 1

Short answer, no. Not really. There is no UltraSPARC V. The 'traditional' SPARC architecture lives on in the M-series, which has SPARC64 CPUs by Fujitsu.
We are jumping from Solaris to RHEL as well. It's possible that we work for the same Canadian ISP, but it's more likely that our companies have made the same decision as dozens of others.

--

"People who do stupid things with hazardous materials often die." -- Jim Davidson on alt.folklore.urban
Re:Single thread performance by mcclungsr · 2011-09-27 09:49 · Score: 1

The T1 had a single FPU shared among 8 cores.. The T3 (and T2) has an FPU per core.
Still, your point about ray-tracing is probably valid, compared to other processors available. If I had a heavily threaded application, I would definitely want to look at T-series SPARCs.
Re:Single thread performance by maraist · 2011-09-27 12:36 · Score: 2

The problem is that hyperthreading CPUs and x64-64 EPIC are predicated around floating point performance. The idea is that if you're FPU bound, then you want to minimize RAM latency by flipping between threads while you have FPU-load stalls.. You add speculative execution, predicate registers, pipeline execution stacks to minimize branch-misses, etc. But it's all about FPU with 200 clock execution times (e.g. divides and transcendental ops - as with FFT).

But I'm sorry, no matter how fast you make their FPUs, they're not going to beat FPGA or ASIC or raw-silicone GPU's. These bastards optimize memory paths and reduce critical path latencies.. The only advantage CPUs have over GPUs is that you can context switch unrelated tasks better than with GPUs.

A vast majority of apps in the world are NOT FPU based. They are pure integer. And moreover, these days, they are RAM constrained.. If your're writing a NoSQL DB procedure to perform zlib or merge-sorting or state-machine syntax parsing, FPU oriented architectures are of ZERO benefit. This is all RAM -> branch-prediction related. That is, read-data, make a decision, jump to new code (which triggers new RAM loads) run two or three instructions, then repeat. While SOME of the app state-tables and code-paths can get cached efficiently, the input stream is generally far larger than your L3 cache (on the order of gigabytes).

So, SOME of the memory pre-loading, branch-prediction, and on-stalled-thread-ctx-switch could be leveraged.. But MT apps suffer from barriers in critical regions.. Namely if you memory stall while holding a lock, you cripple the parallel performance.

Co-processes are very efficient (e.g. apache pre-fork, postgres co-threads with specific shared-mem-segments, erlang, ruby-unicorn, etc) in that they organize very small messages to pass between processes and keep all remaining cache-lines isolated to their single thread and thus semi-dedicated CPUs. This can very nicely leverage co-processors without necessarily saturating RAM -though if the apps themselves are RAM-bound you still have problems; BUT if you have NUMA, the CPU can segment memory spaces better with co-processes than with MT. That being said, the SUN light-weight-threads are (I believe) designed around shared memory-spaces having minimal context-switching time v.s. posix-threads or normal co-processes, so they can't really take advantage of co-processes as well as MT.. So SUN light-threads are forced to endure potentially bad programming by DB, file-IO, OS, signal-processing applications.. Namely if you can't create isolated memory regions (malloc/free-locks, IO/pipe-locks, concurrent-data-structure 'critical-region' locks, etc), you'll find yourself dirtying shared cache-lines so often, you actually find yourself running slower than if you were just single-threaded.

I know, for example, a simple merge-sort can run significantly slower (3x) when run in parallel v.s. single-threaded predominantly because of intel's MESI implementation. Well, not necessarily 3x slower human-time wise, but in consumed CPU time with little or no visible decrease in human-response-time.

As another example, mysql INNODB had a inverse performance curve for the longest time.. Meaning, the more physical CPUs you added, the SLOWER it's total throughput would be.. Predominantly due to excessive critical-region locks. Many of those locks have been replaced with less-accurate atomic spin-locks (as with sequence-counters). Namely you can now 'lose' a primary key's sequential value under the right circumstances - but at the benifit of removing a major classic stall-point. But INNODB is still full of complex algorithms that require critical-regions. Lock-free-code is really hard and is very limiting. But that isn't to say people haven't figured out how to architect good designs. 'redis' NoSQL and erlang based apps (like rabbit-MQ) are good examples.. Namely copy-on-write small data-structures.

But there are two types of apps that have lots of parallel threads. Those with MASSIVE memory requirements and those that

--
-Michael

Not the point of SPARC by Anonymous Coward · 2011-09-27 01:12 · Score: 3, Informative

Is it me, or did Oracle completely miss the point of SPARC? We used to use SPARCs where I work for huge, multi-thread or child-spawning applications. If you want a number cruncher, go somewhere else. Go buy a POWER CPU. SPARC's shining glory is the massively threaded model where you spawn tons of little instances of the same thing that serve a quick, non-intensive purpose and die. Once again, Oracle is taking something they bought and trying to ram the square object into the round hole they call their business model.

Interestingly enough, the captcha for this was "idiots"

Re:Not the point of SPARC by TheLink · 2011-09-27 01:51 · Score: 1

Is there a way for a CPU to make mutex handling easier and more efficient?

Another thing which might be worth looking into speeding up is "gettimeofday" and "trigger on event or register/memory=certain value" - I bet there's lots of code which regularly checks "is it time to do X yet?" or "wait till X happens" (e.g. wait for connection or data).

Maybe these aren't that CPU intensive so speeding them up won't help much in performance?
--
- Too many replies beneath your current threshold
Re:Not the point of SPARC by eclectus · 2011-09-27 02:03 · Score: 4, Insightful

Is it me, or did Oracle completely miss the point of SPARC? We used to use SPARCs where I work for huge, multi-thread or child-spawning applications. If you want a number cruncher, go somewhere else. Go buy a POWER CPU. SPARC's shining glory is the massively threaded model where you spawn tons of little instances of the same thing that serve a quick, non-intensive purpose and die. Once again, Oracle is taking something they bought and trying to ram the square object into the round hole they call their business model.
Interestingly enough, the captcha for this was "idiots"
Do you really think Oracle could turn the ENTIRE chip engineering boat around in a year and a half? This best-of-both-worlds fast single threaded and massively multithreaded design was probably in the works for YEARS before Sun was bought.

--
This signature is a waste of 42 characters
Re:Not the point of SPARC by laffer1 · 2011-09-27 02:09 · Score: 1

gettimeofday calls are a problem for several applications. Postgres and MySQL both had to do some changes to lower the number of times they were called to speed up performance. The problem is that open source software is often designed for Linux. gettimeofday is cheap on Linux because they chose to use a less precise timer than other operating systems. I'm not certain how fast it is in Solaris, but I doubt it's a speed demon. This is a software problem though. The best solution is to update a shared memory segment with the value periodically and just read that from libc. It's a pain to implement though.
I think the argument the GP was making was that less cores means less contention for the lock. Combine that with a faster chip and it is faster. They would need to rewrite large portions of the database to get away from needing mutex. There are other locking strategies as well as ways to write structures that can be read all the time. Some databases are designed to be lock free like couchdb. The problem there is that it's NOSQL and assumes you want to version things and never delete.
Databases are usually lock intensive and many try to do row level locks rather than table locks now.
Intel added instructions to the CPU that can be used for implementing locking primitives that are much faster. I think they're called CAS http://en.wikipedia.org/wiki/Compare-and-swap

--
MidnightBSD: The BSD for Everyone
Re:Not the point of SPARC by davecb · 2011-09-27 03:02 · Score: 1

Linux is not unusual in seeing developers call gettimeofday/gethrtime with wild abandon, thus slowing the programs they're trying to measure the time of (;-)) For this reason, Solaris time calls are register/location reads, and ethe code sequences are so short that they fit into the the syscall dispatch table. Therefor the caller never really enters the OS at all to get the time.
The interesting new work on locks is "transactional memory", and there's a series of articles about it and Linux memory in general at LWN. See Memory part 8: Future technologies by Ulrich Drepper. The hardware they describe as the testbeds are SPARCs.
--dave

--
davecb@spamcop.net
Re:Not the point of SPARC by jmitchel!jmitchel.co · 2011-09-27 03:03 · Score: 1

The direction of the T4 has been set for some time. It's overdue - the single thread performance on the T series is basically miserable and has barely improved since the original T chips. My job involves doing a lot of single thread activities on T series hardware, and that makes me a sad panda.
Re:Not the point of SPARC by hattig · 2011-09-27 03:20 · Score: 1

This chip was probably designed before Oracle finished the takeover of Sun, so saying that Oracle is making this change is quite a leap.
Also the linked article suggests why the design decisions were made in this chip - namely extreme threading compared to the mass market CPUs is getting more and more niche as the mass market CPUs get to 16 threads per socket themselves. Hence this chip going down a higher performance per thread model, with a mode for running a single thread very fast on a core should it need it.
And ultimately you still have the OS scheduler if you want to run more threads than the hardware can handle, and given that the per-thread hardware performance is far higher on this CPU you're not giving up much, if any, threading capability compared to the previous generation.
Re:Not the point of SPARC by ThePhilips · 2011-09-27 03:23 · Score: 1

Is there a way for a CPU to make mutex handling easier and more efficient?
No. It is inherently expensive operation because the updates to critical section must be propagated between all the CPUs/cores (and their caches). CPU ops for mutex itself are puny, compared to the (invisible) mechanics beneath which guarantees the cache coherency. (More CPUs/cores you have - higher the potential overhead.)

Another thing which might be worth looking into speeding up is "gettimeofday" and "trigger on event or register/memory=certain value" - I bet there's lots of code which regularly checks "is it time to do X yet?" or "wait till X happens" (e.g. wait for connection or data).
`gettimeofday` is already optimized and not a real syscall on Linux and Solaris.

Maybe these aren't that CPU intensive so speeding them up won't help much in performance?
They are CPU intensive - but negligible - because they were already heavily optimized.
Overall, GP's suggestion that DB take lots of locks is sort of right - but misses the fact that there are many many locks so collisions are relatively rare. Those are most of the time logical data locks, not real mutexes. And collision are most of the time also of the logical nature: one user tries to update data which are currently being updated by another; one use tried to read data which were updated but not committed by the other; and so on.
DB are generally IO bound: they must provide guarantee that committed data were safely written to disk. This is where the most of DB's performance is wasted - waiting for the disk to do its job.

--
All hope abandon ye who enter here.
Re:Not the point of SPARC by julesh · 2011-09-27 03:26 · Score: 1

Is there a way for a CPU to make mutex handling easier and more efficient?
No. Modern CPUs already support waiting for a spinlock without actually using any execution units (which on a highly-parallel CPU like the Tx processors means the time that would be spent executing them can be allocated to another thread) or any memory bandwidth (by monitoring the cache/memory bus for alterations rather than actively polling). Solaris (and I believe other OSs) will quietly decide whether to use a spinlock or a queue-based system for a mutex lock operation depending on whether the thread that holds it is currently running. Essentially, this is about as efficient as you can get (the queue based system involves a user->kernel->user context switch, but as that's a hotpoint for optimisation for many different scenarios anyway, we can assume that that's already about as good as the CPU designers can get it as well).
Re:Not the point of SPARC by TheLink · 2011-09-27 03:43 · Score: 1

Speaking of slowing the programs, I notice a lot of programs use delays in the order of seconds.

While this might be fine for human facing/usage scenarios, for other scenarios isn't 1 second a very long time for a CPU?

Would delays of 1 millisecond or less be better? Or is there some problem with that? IIRC FreeBSD had some HZ thing, and by default it was 100Hz, so 1 millisecond might be a prob :).
--
- Too many replies beneath your current threshold
Re:Not the point of SPARC by tlhIngan · 2011-09-27 04:08 · Score: 2

Is there a way for a CPU to make mutex handling easier and more efficient?
No. Because mutexes as slow (though highly efficient already).
Most architectures of today provide all the necessary tools to implement lockless algorithms which are more complex, but faster. They're less efficient (because they often do a "try and get lucky" style of processing), but if you have a ton of threads and pretty idle CPUs, it's less of an issue.
And support for this comes in the form of memory barriers (read and write - they're different) and conditional exchange instructions (if value of memory is same as register X, then swap X and memory) up to native word size (or more). The latter is important as you need to be able to swap pointer-sized things atomically.
An example of "try and get lucky" is in singleton object initialization. Say your code instantiates an object, and the object needs ot initialize.
If the object has been instantiated before, you return the existing object. If not, you instantiate and initialize. So far, exactly as how it's done normally, except no lock was taken during the check (!).
Now you initailize the object, and the magic happens near the end. You do a memory barrier to ensure all I/O and memory accesses are done. You then do an atomic compare-and-swap with the memory to hold your instance. If no one else has initialized it yet, it should still be NULL, so you compare with NULL and exchange with your instantiation.
If you succeed, you get the old value of the memory (i.e., NULL). If you fail, you get your instance pointer back (because the exchange failed). If you succeeded, object is initialized. If you failed, someone else initialized it under you, and you destroy the object you initialized and use the one already there.
You can extend this for processing as well - often by using a sequence counter to "flag" what has been done. Or linked lists (being able to verify no one stomped over your next pointer). Or many other structures.
it's less efficient because you're doing more work than necessary (e.g., if you have 100 threads, all 100 may initialize the singleton simultaneously, but only one will succeed and you would throw away the results of the other 99).
Re:Not the point of SPARC by maraist · 2011-09-27 13:08 · Score: 2

"Is there a way for a CPU to make mutex handling easier and more efficient?"
mutex's are VERY efficient with cache-oriented MESI and MOESI instructions, the problem is what you do while another thread owns the mutex. You can either spin-loop or context-switch to another thread. Specifically if thread A locks then has several cache-misses, then thread B would have to spin for thousands of clock-ticks. When you have 80 CPUs that might not be too bad (though it burns power), but if you have 2 CPUs, then that's likely highly wasteful.

"trigger on event or register/memory=certain value"
I believe intel provides a block-until cache-line-updated instruction. I believe that's how Linux futuex and OS-level schedulers work if IIRC.

"I bet there's lots of code which regularly checks "is it time to do X yet?" or "wait till X happens" (e.g. wait for connection or data)."

Well, wait-for-connection is an OS thing. If you use epoll, IO-Completion, kpoll, or even ancient unix 'select' you transfer the overhead of IO to the OS which is very event-driven (and thus doesn't necessarily have a lot of blocking structures). Namely ethernet frame-driver running on CPU-3 can in theory directly transfer to thread-16 after completion which is blocking on a TCP packet when the OS determines it's received enough data to be awoken.

As for 'is it time to do X yet' isn't as bad as you might think (well, I don't have that much imperical evidence, but I've worked in this space).
Instead of 'polling', you can leverage a priority-queue, such that if there is literally nothing critical-to-run, you quickly test the head of the queue for it's execution time-stamp. Then do a time-of-day operation (all while in the OS, so no additional context switching). If a < b you flag the blocking thread for execution (possibly transfering directly to it). Here the slowdown comes when you add/remove an item from the temporal priority-queue (namely O(log(n))). So this is a function of how many temporal waits are scheduled/completed, but is independent of how long it's supposed to wait.. When there is literally no work to perform at all (all CPUs are about to go idle), then you look at your priority-queue and ask how long before the next scheduled event.. Then you can make a CPU go to sleep for that long (using interrupt controllers if need be).
Generally you're going to wake up 32 times a second anyway, and the marginal overhead of re-testing a time against the priority-heap-head 32 times a second is nominal (I can run 800,000 java-based time-of-day calls per second.. plenty of room for those 32).

To boot, the OS doesn't need to know about all the scheduled tasks. It only needs to know about one per thread at most (generally only about 0 .. 3 at any given time, with a few socket-timeout type apps bringing it into the hundreds). Apps can, for example implement their own timer logic that mimics this priority-queue model (java does, for example).. Thus one thread can be OS-bound on a timer that is the nearest temporal event in a pool of potentially thousands of scheduled events (e.g. a Java Timer or memory-based Quartz).

What I see the greatest problem with are peer-CPU's modifying common cache lines..

Namely if you have a job-queue data-structure where N threads are pulling/pushing out-of/on-to, then you have a single spot in memory that EVERY thread must modify in order to transfer work.. This is a massive bottleneck.. One that ironically you don't have in single CPU configurations. This is something that I think CPUs can work to address. Especially as co-process and message-passing systems become more prevelant (erlang type languages or message-queue NoSQL models).

One reason Intel CPUs suffer from this is that when two CPUs concurrently modify a cache-line, everybody is forced to 'flush' their cache line and re-read from RAM.. This not only makes those accesses no faster than main RAM, it's competing with everything else you want to do with RAM - increasing latancy massiv

--
-Michael
Re:Not the point of SPARC by maraist · 2011-09-27 22:52 · Score: 1

"DB are generally IO bound: they must provide guarantee that committed data were safely written to disk. This is where the most of DB's performance is wasted - waiting for the disk to do its job.".
Sometimes. When they are IO bound, then yes, locks are of trivial importance. But DBs generally also serve as massive coherent caches and lock-managers. And those caching operations are VERY susceptible to critical-region code. Namely MySQL INNODB had an inverse performance characteristic with the number of CPUs for a long while. Further, recently, it was shown that by skipping the SQL layer of MySQL-INNODB and using simple direct HTTP calls into the storage layer, performance was improved measureably.

There's no accounting for bad code (which is most likely the case with MySQL optimizations), but I definitely feel that the programming world is solely inadequately prepared for multi-threaded programming.

Basically we need to focus on lock-free algorithms (or wait-free, or read-lock-free as appropriate). They should focus on optimisitic locks instead of pessimistic locks. Use compare-and-set operations/spin-loops. Use stack / context-variables instead of globals, etc. But most people just think in their 1960s sequential style and go; oh, two guys touch this so let me throw in a mutex. Then you find when you double the CPU count (or even machine count) that the system degrades miserably.

--
-Michael
Re:Not the point of SPARC by maraist · 2011-09-27 23:11 · Score: 1

"Essentially, this is about as efficient as you can get"
I don't know about that. alpha/AMD added the 'mesh' CPU network, where you talked to routed neighbors for memory/BUS access, and thus not every CPU needs to spin it's transistors on cache operations. I don't know how advanced that got, but there's no reason that N,S,E,W cache controller nodes can't determine the scope of dissemination of cache-reads, and thereby localize snoop and lock-cache-line calls. Compre-and-set can be implemented IN the cache-line. You've got an address-line and a data-line. Why not add a cas bit on the routed bus and say 'Here's the old data, and it's address, and set the cas bit; then on the next clock, the data line will contain the new data. The mem-controler reponds with a read-complete operation or invalid'. You already have comparison logic for the address lines in their fully-associative cache logic; no reason you can't implement CAS there too.

So now you completely avoid a BUS-lock.. The cache atomicly (within a cache-clock-tick) owns the data.

I'm not a fan of mutex-spin-locks, because most algorithms that are fast enough to warrent a context-switch-free operation generally can use an optimistic-locking algorithm. Thus, I believe OS ctx switches or CPU-oriented thread-swap operations are field (e.g. some type of yield operation). But there are integer or pair-of-integer algorithms that can make heavy use of such CAS operations. And generally, the first step of a mutex is such a CAS.

If you were crazy enough to want to use semaphores instead of mutex's (hopefully because you actually want a constrained resource count, and not because you just prefer semaphores), then this CPU operation wouldn't make sense.. I doubt you want a full-on adder in the cache-controller (though I suppose that's possible too). Namely instead of 'lock; xadd [m1], 1'. You'd have "st_add [m1], 1" where the cache-controller is required to implement read, add, re-write (atomicly) instead of having the CPU do it.

Next is the furthered notion of topological CPU configurations.. Namely, pin thread-5 to CPU-2 then pin thread-6 t CPU-3 (which is adjacent), and the OS tells both CPUs that a shared memory segment (including mutex regions) is ONLY available to those two CPUs. And thus you can pass synchronous control signals between them.. Again, special instructions are required.. But now you can use 'barrier' instructions.. Similar to an idle spin loop (wait until barrier signal arrives from co-processor indicating the pipeline of work has new data. But this now starts competing with GPUs and CELL processors.

I'm sure there are other possible operations, such as direct register to remote-CPU register transfer operations.. Similar in principle to the SUN SPARC register window, you can have an in/out suite of registers where instead of function-call communication, we're facilitating asynchronous co-processors pipeline communication operations.

There are code paths that make sense to implement these sort of pipeline co-process architectures. Any place a 'spawn task' operation happens, that can be optimized in assembly + OS as a co-process pair. You would need some specialized C function APIs:

Future f = DispatchTask(data_structure); // co-process/ co-thread dispatch ....
mytype result = f.get(); // co-process barrier (CPU might context switch to peer thread)

--
-Michael

Re:high end CPUs from the database company by NoNonAlphaCharsHere · 2011-09-27 01:13 · Score: 4, Funny

Well, in fairness, they did add an evil bit(TM) to the flags register. Unfortunately, in Oracle's case, "jump on evil" is an unconditional branch.

Oracle? by aglider · 2011-09-27 01:21 · Score: 1, Insightful

Oracle is as deep in CPU technology as Berlusconi is deep in reliability.
Maybe it'd read "SUN, an Oracle acquisition, will demo a new T4 Sparc CPU".

--
Sent as ripples into the electromagnetic field. No single photon has been harmed in the process.

Does that make any sense? by aglider · 2011-09-27 01:23 · Score: 3, Insightful

I mean, to (re)introduce a new CPU in the market?
Either the T4 can run Oracle SQL in silicon or it won't fit in between the Intel/AMD mature technology on one side and the rising (and power saving) ARM on the other one.
Yes, you can build an "Oracle appliance" with whatever CPU you want, even your very own design. But then will the market share justify the efforts in CPU design?

No, I don't think they won't ever succeed.

--
Sent as ripples into the electromagnetic field. No single photon has been harmed in the process.

Re:Does that make any sense? by EthanV2 · 2011-09-27 01:30 · Score: 2

No, I don't think they won't ever succeed.
Sooo... You think that they will succeed?
Re:Does that make any sense? by Kjella · 2011-09-27 01:37 · Score: 1

Either the T4 can run Oracle SQL in silicon or it won't fit in between the Intel/AMD mature technology on one side and the rising (and power saving) ARM on the other one.
If you think the T4 is even remotely in the same market as ARM you're only showing your own ignorance. They're more in league with IBM's POWER7 and Intel's high end Xeons, running massive servers.

--
Live today, because you never know what tomorrow brings
Re:Does that make any sense? by angel'o'sphere · 2011-09-27 02:01 · Score: 3, Informative

# prstat
Total: 341 processes, 9909 lwps, load averages: 20.86, 19.36, 20.41
# prtdiag -v
System Configuration: Sun Microsystems sun4u SPARC Enterprise M9000 Server
System clock frequency: 960 MHz
Memory size: 262144 Megabytes
Only roughly 3 processes per core ... and yes that is 262 GIGA BYTES of Ram. How much again can an ARM address?
Well, keep in mind: when we talk about SPARC or the Power PC architecture we also talk about memory bandwidth, failover safety, attached I/O devices etc.
I don't see anyone trying to build "big iron" with ARMs right now.

--
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Re:Does that make any sense? by davecb · 2011-09-27 03:07 · Score: 1

You don't run the sql in silicon to speed things up, you worry about the speed of joins in main memory.
--dave

--
davecb@spamcop.net
Re:Does that make any sense? by aglider · 2011-09-27 03:10 · Score: 1

NO, they won't. Typpo!

--
Sent as ripples into the electromagnetic field. No single photon has been harmed in the process.
Re:Does that make any sense? by aglider · 2011-09-27 03:13 · Score: 1

I do am ignorant. But I think I know the difference, technical and comemrcial, between Intel, AMD, ARM, POWER7, Alpha and so on.
I simply say, there's no room in the market for another CPU, as almost all of the "atlernative" ones already failed.

--
Sent as ripples into the electromagnetic field. No single photon has been harmed in the process.
Re:Does that make any sense? by aglider · 2011-09-27 03:16 · Score: 1

Correct.
Do you why none (else) is building "big iron" like that?
Probabily because too few people is asking for them.
The market buzzwords are "cluster" and "clud". Not "big iron".
I don't mean that real 64bit hardware is not good. I meat it hardly will succeed.
You know the glorious story of the wonderful Motorola 68K and 88K. Beautiful CPUs, stinky business.

--
Sent as ripples into the electromagnetic field. No single photon has been harmed in the process.
Re:Does that make any sense? by aglider · 2011-09-27 03:20 · Score: 1

Yeah! That's the RDBMS duty! Which is software.
So what'd the be the plus of yet another RISC CPU?
With super-pipelined Intels and AMDs behaving almost like RISC, with multimegabyte L3 caches and so on, the gap between RISC and CISC is almost zero.
Apart of the power hunger.
Mine was humor, anyway. A CPU running SQL in silicon is an absurdity.

--
Sent as ripples into the electromagnetic field. No single photon has been harmed in the process.
Re:Does that make any sense? by the+linux+geek · 2011-09-27 03:28 · Score: 1

Nobody else is making big iron? IBM, HP, Fujitsu, Unisys, Hitachi, NEC, and Groupe Bull are just irrelevant?
Re:Does that make any sense? by joshuac · 2011-09-27 04:38 · Score: 1

Memory size: 262144 Megabytes
Only roughly 3 processes per core ... and yes that is 262 GIGA BYTES of Ram. How much again can an ARM address?
Just a minor detail, that looks more like 256 "GIGA BYTES".
Re:Does that make any sense? by Anonymous Coward · 2011-09-27 05:52 · Score: 1

It's a server chip. The massive threading they've got right, and it's great for that, but servers aren't just about running oodles of servlets - although that's a huge part of it. The T4 will doubtless outperform any Intel competitor at the same number of simultaneous threads because Sun has that part of the internals down just right and Intel does not.
The absolutely fastest arrangement Intel has is 4-way SMP, 6-way internal cores, 12 threads per core. (4x6x12) And I do not believe Intel has done any serious work on SMP in a very long time, so the 4-way may no longer be possible. So 72 threads is you're most likely limit, 288 threads is the absolute limit Intel could hope to deliver if they provide an SMP chipset capable of supporting the latest i7 CPUs.
With the T4, you're limited to a 16-way SMP, 8 internal cores and 8 threads, giving you a 16x8x8 arrangement. That's 1024 simultaneous threads across the entire arrangement.
Sure, you could build an Intel cluster that matches or beats a T4 system, but the less tightly-coupled your system is, the slower the internal communication and the more complex the message navigation becomes, so although it would beat the T4 on raw power, most of that raw power is unusable due to latency.
Re:Does that make any sense? by blue_teeth · 2011-09-27 06:11 · Score: 1

Amen to this.
For the basement types x86 desktop guys. While the whimpering noise you make, please visit a Enterprise Class Datacenter of a large organization (if you are allowed inside). An hour downtime of their Operations System would result in couple of million dollar (USD) costs. This is where Sparc and Power PCs run.
Please do not compare your Suzukis with a McLaren F1's. (Its a theoretical argument).
Yes, I have migrated large enterprise Operations Systems from Sparc to x86_64 (Opteron).
Re:Does that make any sense? by Darinbob · 2011-09-27 07:02 · Score: 1

This is not a new CPU trying to squeeze in, this is an upgrade to a CPU that is already in the market!
And if society kept saying "we already have one of those, thank you very much" we'd never make any progress at all.
Re:Does that make any sense? by cthulhu11 · 2011-09-27 17:46 · Score: 1

... not to mention the freedom from BIOS and anachronistic video consoles
Re:Does that make any sense? by maraist · 2011-09-28 11:58 · Score: 1

I am suspicious of such numbers. You need to pick an application and run it on two machines for comparison. Number of active threads is independent of the number of CPUs - and while this means overhead in context switching into and out-of CPUs, if the reason they're stalled is memory throughput or disk IO, then CPU context switching is irrelevant.. And guess what, the memory throughput has little to do with the CPU.. Namely you can construct a NUMA motherboard where each CPU has localized RAM (and thus unaffected by threads in other zones).

The main reason I call BS on 2, 4 or 16 threads per core is that this explicitly only allows a single actively running thread; it merely means that IF you can do NON RAM work in the other 15 threads, then when thread-1 stalls you can get useful work done by quickly switching without OS interaction. But that's a big IF.

--
-Michael

price? by dutchwhizzman · 2011-09-27 01:25 · Score: 1

Will it be able to compete with HP and Dell servers in price this time? 8 core intels cost less than 10K these days, I hope SUN^wOracle will start understanding competitive pricing for a change.

--
I was promised a flying car. Where is my flying car?

Re:price? by backslashdot · 2011-09-27 01:41 · Score: 1

According to the article, apparently they make up for that by charging extra if you want to run Oracle database on an x86 CPU.
Re:price? by eclectus · 2011-09-27 02:07 · Score: 1

remember, 8 cores, 8 threads per core, multiple chips per system. I'm sure it's able to be LDOM'ed out as well, so you could in theory have up to 256 single-threaded seperate servers running in this one box. Not in the same league as a little dell/HP box. Like someone else said, This is going after IBM P7. Or people who really want to consolidate.

--
This signature is a waste of 42 characters
Re:price? by TheSunborn · 2011-09-27 03:21 · Score: 1

A shame that the benchmarks show that any decent x86 dual-processor box Hp or Dell will beat this box in both price and performance. (But not in power usage) The thing I don't understand is: If you have code which are multit-hreaded enough to max out a T3, then the T4 will not give you any performance benefit. This is odd, considering how old the T3 is.
Re:price? by Bengie · 2011-09-27 04:09 · Score: 1

Great for servers, bad for clusters. Very power efficient, but very picky on the type of work they do. Very expensive, but worth it if you need high densities.
Semi-niche market.

But - by Anonymous Coward · 2011-09-27 01:37 · Score: 1

Will it run Linux?

Re:But - by xmorg · 2011-09-27 01:57 · Score: 1

No, but it runs FreeBSD

Pricing? No, *licensing* by Brandon+Hume · 2011-09-27 01:48 · Score: 2

It's all very nice that they've decided to try and up the single-thread performance. However, it's worth noting that the only thing worthwhile to run on a SPARC nowadays (thanks to Oracle's PMITA licensing structure) is Oracle DB. You buy an Oracle box to run Oracle. Any other workload is nonsensical, as you'll get better single-thread performance from x86, and you'll get way more cycles per dollar from... well, just about any other hardware/OS combination out there.

So as you consider purchasing this higher-clocked box, I've been told that the Oracle licensing for this machine will be 0.5 per core, while the T3 is 0.25 per core. Basically Oracle will cost approximately twice as much per core on this machine. I'm not a DBA... does that make any sense, when databases are traditionally I/O-bound?

Incidentally, my first paragraph caused me pain to type... I'm my organization's SPARC and Solaris expert, and I was a big pusher of the platform. Oracle's takeover and subsequent psychotic support costs and absolute blindness to any workload not DB-oriented was a fair kick in the pants to me. I'll fully admit that I'm not impartial.

--
Brandon Hume
hume -> BOFH.Halifax.NS.Ca, http://WWW.BOFH.Halifax.NS.Ca/

Re:Pricing? No, *licensing* by angel'o'sphere · 2011-09-27 02:18 · Score: 1

Basically Oracle will cost approximately twice as much per core on this machine. I'm not a DBA... does that make any sense, when databases are traditionally I/O-bound?

The matter with traditions is that they are outdated at some point. DBs are no longer I/O-bound since typical querries return gigabytes of results that need to be joined and ordered. At least in our days universities have research projects running to utilize the CPU better in modern DBs.

--
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.

Cores? by Bigbutt · 2011-09-27 02:20 · Score: 1

Considering the licenses are for the number of cores, changing the number of cores from 16, or 32, or 256 to 8 cores would certainly bring the Oracle DB license costs down again. And since that's the reason we haven't been upgrading our Sun systems and have been moving to Dell R710's or HP, there might be some strategy involved from Sun (since this couldn't have been something that took a bit over a years to produce).

[John]

--
Shit better not happen!

Re:Pricing? No, *licensing* by Bigbutt · 2011-09-27 02:22 · Score: 1

I'm with you and am a big supporter of Solaris and Sun but the Oracle licensing costs were killing the company and killing me since I couldn't get new Sun boxes to replace the old gear. Hence the move to Dell and HP and the transition to mysql for the database side (although when Oracle bought Sun, it threw a bit of a wrench into the works).

[John]

--
Shit better not happen!

yo dawg by decora · 2011-09-27 02:36 · Score: 1

i heard you like threads, so i put a CPU in your CPU so you could give all your money to Larry Ellsion while you give all your money to Larry Ellison!

Re:yo dawg by V!NCENT · 2011-09-27 06:57 · Score: 1

I saw a T4 blade version with 300GB costing around 600 euro's and a terminal costing around 100 euro's, so I figured that a rack/workstation could add up to just around a 1000 dollars. But according to the replies, this is probably impossible to get (1) and worthless for anything that doesn't float (2).
Sadly...

--
Here be signatures
Re:yo dawg by V!NCENT · 2011-09-27 06:58 · Score: 1

Correction: Worthless for floating point.

--
Here be signatures

I'm not dead yet by mevets · 2011-09-27 02:38 · Score: 1

Really, I'm feeling quite a bit better.

It would be nice to see sun rise again; although masters of their own demise, they have suffered the way Brittany did.

Re:high end CPUs from the database company by ThePhilips · 2011-09-27 03:00 · Score: 1

No no. You should familiriaze yourself with Oracle DB.

The CPUs are busy colliding on SQL statement cache global lock.

--
All hope abandon ye who enter here.

Re:Pricing? No, *licensing* by hattig · 2011-09-27 03:28 · Score: 1

So you would prefer that they had 16 of the T3 cores at 0.25x per core? Running at maybe 2GHz each because of the design?

Nah, 8 T4 cores at 0.5x per core, and far greater per-core performance, seems to be a better deal to me. You might lose half of your threads per CPU, but as the article says, that level of threading is getting more and more niche.

But not as good a deal as not using Oracle in the first place.

Re:Sparc runs Linux too by ThePhilips · 2011-09-27 03:31 · Score: 1

I was under impression that HP offered us a sweet deal on x64 servers (ProLiants) our management couldn't refuse. And why on earth run a Linux on proprietary hardware?

Old SPARCs would remain of course, but only for purposes of support and maintenance of old versions of our software.

We have bunch of old T2 - and they ... suck. Even on highly multithreaded Java workloads.

--
All hope abandon ye who enter here.

Re:Pricing? No, *licensing* by Bigbutt · 2011-09-27 04:28 · Score: 1

Got me. I'm in operations, not in development.

[John]

--
Shit better not happen!

Re:FAIL AT FIXING IS FAILURE by Anonymous Coward · 2011-09-27 06:10 · Score: 1

No, it looks exactly like 262 GIGABYTE and 256 GIBIBYTE

There's no such thing as a gibibyte no matter how much idiots wish for it.

Re:Sparc runs Linux too by tqk · 2011-09-27 06:10 · Score: 1

Redhat dropped SPARC ages ago.

Fine. Slackware for Sparc

--
"Tongue tied and twisted, just an Earth bound misfit ..." -- Pink Floyd.

Re:high end CPUs from the database company by DoctorPepper · 2011-09-27 06:13 · Score: 1

I wish I had mod points, that made me laugh! :D

--

No matter where you go... there you are.

Re:Sparc runs Linux too by swordgeek · 2011-09-27 06:41 · Score: 1

Actually, you can pretty much blame that on Java - it's a disaster on highly parallel gear. (We got Sun to eventually admit that, after a disastrous aborted rollout of Directory Server on T series machines.)

Still - The T machines are very much a niche market, and that niche is disappearing quickly. I suspect there will never be a T5 processor with any significant changes.

Good luck with the ProLiants. They ain't what they used to be, according to a friend recently ex- of HP.

--

"People who do stupid things with hazardous materials often die." -- Jim Davidson on alt.folklore.urban

Re:Sparc runs Linux too by ThePhilips · 2011-09-27 06:49 · Score: 1

Good luck with the ProLiants. They ain't what they used to be, according to a friend recently ex- of HP.

They are just generic x64 servers, with a decent support contract from HP. I doubt they are worse or better than the cheap generic Intel boxes from any other manufacturer.

--
All hope abandon ye who enter here.

Re:Sparc runs Linux too by WorBlux · 2011-09-27 08:37 · Score: 1

Almost all hardware is proprietary. Perhaps you mean uncommon? Anyways the designs of the T1 and T2 have been publicly released. http://www.opensparc.net/about.html

Re:Sparc runs Linux too by ThePhilips · 2011-09-27 08:52 · Score: 1

CPU specification != system architecture.

The former is mostly about wiring a CPU. And instruction set.

The latter is about: memory and memory controllers, IO controller, interrupt controllers, external RTCs, and the rest of carp you usually find soldered on a motherboard. All the carp for which the OS requires a proper driver.

While CPU spec might be free, the rest of the controllers, which are required to bring up the system, are mostly proprietary H/W.

--
All hope abandon ye who enter here.

Re: wait periods (was:Not the point of SPARC) by davecb · 2011-09-27 11:14 · Score: 1

If I want to let other programs make progress, I'll put myself to sleep for human kinds of time periods, like "the rest of the second" for small waits, 1-3 seconds for big ones, and up to 10 if I can signal the human with something like a watch cursor.

--dave

--
davecb@spamcop.net

Re:Sparc runs Linux too by swordgeek · 2011-09-27 11:40 · Score: 1

Fair enough. It's just that up until about three years ago, the Proliants were solid and beautiful tanks, which were almost on par with the new Sun gear at the time.

--

"People who do stupid things with hazardous materials often die." -- Jim Davidson on alt.folklore.urban

Re:Sparc runs Linux too by segin · 2011-09-27 15:09 · Score: 1

No, the x86 platform is not "proprietary". It may have proprietary extensions (GPU acceleration features, etc.), but there is a universal base set of hardware interfaces and behaviours that every single x86 machine has. And this base set is openly documented, in full, no NDAs required.

Re:Sparc runs Linux too by dbIII · 2011-09-27 15:45 · Score: 1

These days a whitebox with a SuperMicro board is a lot cheaper with more features at the high end. At the low end I don't know why you would bother looking at HP.
HP stopped moving but the rest of the world didn't.

Re:Sparc runs Linux too by WorBlux · 2011-09-27 19:57 · Score: 1

That means it's not secret and standard compliant,, not that anyone can go a manufacture x86 processors with the modern instruction sets) without paying licencing fees or having a large patent pool of their own to do cross-licencing with. But this isn't quite true anyways, Intel hasn't released full spec sheets on their chipsets since the Pentium two or three making it really hard to get coreboot running on modern intel boards.

Re:Sparc runs Linux too by ThePhilips · 2011-09-27 22:48 · Score: 1

These days a whitebox with a SuperMicro board is a lot cheaper with more features at the high end. At the low end I don't know why you would bother looking at HP.
HP stopped moving but the rest of the world didn't.

You missed the bit about "decent support contract." We need our suppliers to be able to provide customers with systems which they can support for 5-10 years. Except for the HP, IBM and Sun/Oracle very few companies are doing it.

--
All hope abandon ye who enter here.

Re:Sparc runs Linux too by dbIII · 2011-09-28 02:11 · Score: 1

Ok, missed that, mostly because in my part of the world support contracts are crap and typically involve some teenager fresh out of a tech course flying in the day after you need them to attempt to perform some task they do not understand and have never done before. I bought a couple of spare IBM tape drives and autoloaders for less than their yearly support cost after one such incident.
Dell of course are several times worse. HP don't really do much support near me.
I got stuff from Racksaver/Verari for a while but they changed their on site support policy to return to base on the other side of the fucking world (and then the courier put a forklift tine through the server on the way back). "Decent support" depends entirely on who is employed doing it in your local area, and if you don't know it's worth finding out before you get stung.

Re:Sparc runs Linux too by Pieroxy · 2011-09-28 07:00 · Score: 1

Actually, you can pretty much blame that on Java - it's a disaster on highly parallel gear.

Do you have references for that? In my experience, Java handles threads mostly well. The last experience I have was on a 16CPU Sun beast (don't remember the model unfortunately). Is that a deficiency of Java on this architecture?

--
Write boring code, not shiny code!

Re:Sparc runs Linux too by swordgeek · 2011-09-28 16:39 · Score: 1

The advantage of dealing with a big name comes of being a big player with a big support contract.
Our division within the company runs about 1800 unix servers right now. That doesn't include the switches, the storage, workstations, etc. etc.. That kind of clout gives us traction when we call for support on a system.

If I'm prepared to spend six or seven figures on annual support, then the big companies actually make sense. If I'm looking at a few to a few dozen servers, then no--go with something small, and do your own in-house support.

--

"People who do stupid things with hazardous materials often die." -- Jim Davidson on alt.folklore.urban

Slashdot Mirror

Oracle Demos New SPARC T4 Processor

87 of 127 comments (clear)