Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Oracle Demos New SPARC T4 Processor

timothy posted more than 2 years ago | from the store-away-from-volatile-gases dept.

Oracle 127

MojoKid writes "Oracle is publicly demonstrating its new T4 processor today and is shipping beta test systems to selected partners. The new T4 chip is a major departure from previous designs. The T4 offers a maximum of eight cores per physical chip and keeps the T3's eight-threads-per-core limitation. The T4 compensates for its lower maximum theoretical throughput in several ways. First, the T4 is an out-of-order processor with an enhanced branch predictor. Its maximum speed is said to be at least 3GHz, nearly double that of the 1.67GHz T3. Oracle claims the chip's single-threaded performance has been significantly boosted, and expects T4 to deliver a 2x-7x speed increase in single-threaded workloads compared to T3."

cancel ×

127 comments

Single thread performance (1)

toQDuj (806112) | more than 2 years ago | (#37525346)

"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.

Re:Single thread performance (1)

lanc (762334) | more than 2 years ago | (#37525406)

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?

Re:Single thread performance (1)

spiffmastercow (1001386) | more than 2 years ago | (#37525636)

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 (1)

Vectormatic (1759674) | more than 2 years ago | (#37525686)

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

Re:Single thread performance (1)

Anonymous Coward | more than 2 years ago | (#37526150)

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 (1)

ThePhilips (752041) | more than 2 years ago | (#37526598)

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.

Sparc runs Linux too (1)

unixisc (2429386) | more than 2 years ago | (#37526772)

But won't RHL6 run on Sparcs as well, like current RHEL 5 does? Such a change shouldn't prevent them from continuing to use their old Sparcservers. Of course, if they're moving away from Oracle, they may not care to buy any T4 based systems - at least not from Oracle.

Re:Sparc runs Linux too (0)

Anonymous Coward | more than 2 years ago | (#37526910)

Redhat dropped SPARC ages ago. Any EL5 SPARC build you might have seen was built by a third party and isn't supported by Redhat.

Re:Sparc runs Linux too (1)

tqk (413719) | more than 2 years ago | (#37529228)

Redhat dropped SPARC ages ago.

Fine. Slackware for Sparc [splack.org]

Re:Sparc runs Linux too (1)

ThePhilips (752041) | more than 2 years ago | (#37527006)

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.

Re:Sparc runs Linux too (1)

swordgeek (112599) | more than 2 years ago | (#37529604)

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.

Re:Sparc runs Linux too (1)

ThePhilips (752041) | more than 2 years ago | (#37529714)

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.

Re:Single thread performance (1)

swordgeek (112599) | more than 2 years ago | (#37529504)

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.

Re:Single thread performance (2)

FreakyGreenLeaky (1536953) | more than 2 years ago | (#37526100)

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 (1)

segedunum (883035) | more than 2 years ago | (#37526420)

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 (1)

TheRaven64 (641858) | more than 2 years ago | (#37526570)

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.

Re:Single thread performance (1)

spiffmastercow (1001386) | more than 2 years ago | (#37526806)

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 (2)

Bengie (1121981) | more than 2 years ago | (#37528254)

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 (1)

Anonymous Coward | more than 2 years ago | (#37526580)

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 (1)

afidel (530433) | more than 2 years ago | (#37529376)

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.

Re:Single thread performance (0)

Anonymous Coward | more than 2 years ago | (#37525426)

Whatever benefits Oracle DB the most.

Re:Single thread performance (4, Interesting)

MetalliQaZ (539913) | more than 2 years ago | (#37525634)

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

Re:Single thread performance (0)

Anonymous Coward | more than 2 years ago | (#37526616)

It's not been refocused per-se, it's more that it's been made even more multi-purpose.

Let's say you load up a T4 based box with several containers (Solaris 10 para-virtualization - think enhanced chroot'd jails), one or two for database, a couple for web services, and a couple for file transfer services. Each of these containers will share resources as defined by the administrator who set the box up. Single thread hungry apps like the database will perform well, while the multi-thread apps like the web services will also thrive.

Re:Single thread performance (0)

Anonymous Coward | more than 2 years ago | (#37525450)

Ridiculous. It's as if Intel started to design for low power, or ARM for high performance.

Seems like the industry is marching towards unification of design goals. Having the best product for part of the market is no longer interesting, you must be a player in "whatever everybody is doing these days".

Re:Single thread performance (0)

Anonymous Coward | more than 2 years ago | (#37526174)

Ridiculous. It's as if Intel started to design for low power, or ARM for high performance.

Am I really the only one who remembers that ARM 2/3 originally did outperform Intel 80386/i486 vastly? In the late 1980s, when x86 was just over 1 MIPS, ARM was at 8 MIPS.

Re:Single thread performance (0)

Anonymous Coward | more than 2 years ago | (#37526462)

Yes, you are. I'll get off your lawn now, mister.

Re:Single thread performance (1)

V!NCENT (1105021) | more than 2 years ago | (#37525640)

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? >:-)

Re:Single thread performance (1)

owlstead (636356) | more than 2 years ago | (#37526136)

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 (0)

Anonymous Coward | more than 2 years ago | (#37526154)

These are full-power cores, though, not the ultra-simplified stuff you see in GPUs. It's designed for extremely high-load systems - heavily-used web servers, for instance. It's actually a very interesting design - each "core" is a sort of barrel processor. Every clock, it runs the next thread. If it's blocked, waiting for memory access, it just goes to the next one. With that many threads, it's effectively never running NOPs because it's waiting on memory, so that 1.67gHz is a lot more efficient than an equivalent x86, POWER or Itanium. It also doesn't need nearly as much cache - the T3 had only 6MB of L2 cache, compared to 30MB of L3 cache on Xeon E7s (on top of 2MB of total L2 cache).
Unfortunately, it's not a workstation chip at all. I'm checking Oracle's website, and every single one of those servers is "price by request". But when they're selling a 600GB hard drive for it for over a grand, I think it's safe to say that you're more likely to see a workstation based on ARM than based on that.

yo dawg (1)

decora (1710862) | more than 2 years ago | (#37526378)

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 (1)

V!NCENT (1105021) | more than 2 years ago | (#37529808)

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...

Re:yo dawg (1)

V!NCENT (1105021) | more than 2 years ago | (#37529822)

Correction: Worthless for floating point.

Re:Single thread performance (1)

Bengie (1121981) | more than 2 years ago | (#37527440)

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.

Oh... (0)

neokushan (932374) | more than 2 years ago | (#37525368)

Well that's nice. Good for Oracle.

Re:Oh... (0)

Anonymous Coward | more than 2 years ago | (#37525454)

Good for us, too. The more competition the better. And that machine seems competitive. Welcome back from the dead, Sparc!

high end CPUs from the database company (0)

Anonymous Coward | more than 2 years ago | (#37525418)

err... OK. Guess they gotta parse those SQL statements.

Re:high end CPUs from the database company (4, Funny)

NoNonAlphaCharsHere (2201864) | more than 2 years ago | (#37525474)

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.

Re:high end CPUs from the database company (1)

DoctorPepper (92269) | more than 2 years ago | (#37529262)

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

Re:high end CPUs from the database company (1)

ThePhilips (752041) | more than 2 years ago | (#37526634)

No no. You should familiriaze yourself with Oracle DB.

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

Time machines work in reverse? (1)

said213 (72685) | more than 2 years ago | (#37525446)

“The spread of civilisation may be likened to a fire; First, a feeble sparc, next a flickering flame, then a mighty blaze, ever increasing in speed and power.” - Nikola Tesla

Single threaded. Teh Futar has arrived.

Not the point of SPARC (3, Informative)

Anonymous Coward | more than 2 years ago | (#37525470)

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 (0)

Anonymous Coward | more than 2 years ago | (#37525592)

Meanwhile, a big purpose of database code is acquiring MUTEX locks. Having lots of cores running spinlocks doesn't make a lot of sense for them.

Re:Not the point of SPARC (1)

TheLink (130905) | more than 2 years ago | (#37525828)

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?

Re:Not the point of SPARC (1)

laffer1 (701823) | more than 2 years ago | (#37526046)

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 [wikipedia.org]

Re:Not the point of SPARC (1)

davecb (6526) | more than 2 years ago | (#37526658)

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 [lwn.net] by Ulrich Drepper. The hardware they describe as the testbeds are SPARCs.

--dave

Re:Not the point of SPARC (1)

TheLink (130905) | more than 2 years ago | (#37527118)

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 :).

Re:Not the point of SPARC (1)

ThePhilips (752041) | more than 2 years ago | (#37526920)

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.

Re:Not the point of SPARC (1)

julesh (229690) | more than 2 years ago | (#37526946)

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 (2)

tlhIngan (30335) | more than 2 years ago | (#37527476)

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 (4, Insightful)

eclectus (209883) | more than 2 years ago | (#37525960)

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.

Re:Not the point of SPARC (1)

jmitchel!jmitchel.co (254506) | more than 2 years ago | (#37526672)

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 (1)

hattig (47930) | more than 2 years ago | (#37526880)

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.

Oracle? (1, Insightful)

aglider (2435074) | more than 2 years ago | (#37525536)

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".

Does that make any sense? (3, Insightful)

aglider (2435074) | more than 2 years ago | (#37525564)

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.

Re:Does that make any sense? (2)

EthanV2 (1211444) | more than 2 years ago | (#37525626)

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

Sooo... You think that they will succeed?

Re:Does that make any sense? (1)

aglider (2435074) | more than 2 years ago | (#37526748)

NO, they won't. Typpo!

Re:Does that make any sense? (0)

Anonymous Coward | more than 2 years ago | (#37527628)

Ah, double negatives. How can't you not love them?

Re:Does that make any sense? (1)

Kjella (173770) | more than 2 years ago | (#37525678)

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.

Re:Does that make any sense? (1)

aglider (2435074) | more than 2 years ago | (#37526784)

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.

Alternative CPU's? (0)

Anonymous Coward | more than 2 years ago | (#37527848)

Excuse me butwhen was there such alternative CPU's? Intel stole patents and used bribes to shut-down HP's PA-RISC and HP/Compaq's DEC Alpha. Microsoft bribed CEO's of Caldera and Sun to disappear off the face of the earth while slinging lawsuits and FUD at neighboring competitors. SGI similarly had leadership problems that it stagnated, but it's talent all moved independently to Nvidia if not Intel and ATI/AMD.

The two major infiltraitors are the Intel and Microsoft chaingang, both of which have ruined more companies a,d removed product diversity, scalability, and quality. In a world of art in science, Intel and Microsoft are taggers and counterfeiters. They were the alternative that used granted research money to ruin fields of expertise to force customers and competitors to their own propriety. Consumers voted with money too, and now everyone suffers withese two obese Alternatives becoming the main line of only-available products.

Have a nice day, sir.

Re:Does that make any sense? (0)

Anonymous Coward | more than 2 years ago | (#37528166)

SPARC is not a new architecture. You might not have come across it, but that is a different issue entirely. The T4 is the latest in a long line of SPARC CPUs, and enterprise level customers have been incredibly happy with them.

I am not aware of any CPU which runs SQL statements natively; that would be quite an achievement, but the architecture would have to be very complex to allow for execution of non-SQL code (such as a kernel) on a more traditional instruction set. That would be an architecture that would be very difficult to introduce into the market!

Re:Does that make any sense? (1)

Darinbob (1142669) | more than 2 years ago | (#37529880)

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? (3, Informative)

angel'o'sphere (80593) | more than 2 years ago | (#37525940)

# 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.

Re:Does that make any sense? (1)

aglider (2435074) | more than 2 years ago | (#37526830)

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.

Re:Does that make any sense? (1)

the linux geek (799780) | more than 2 years ago | (#37526964)

Nobody else is making big iron? IBM, HP, Fujitsu, Unisys, Hitachi, NEC, and Groupe Bull are just irrelevant?

Re:Does that make any sense? (0)

Anonymous Coward | more than 2 years ago | (#37527386)

My mother was a fujitsu you insensitive clud.

Re:Does that make any sense? (0)

Anonymous Coward | more than 2 years ago | (#37526962)

processes != threads.

Re:Does that make any sense? (1)

joshuac (53492) | more than 2 years ago | (#37527852)

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".

FAIL AT FIXING IS FAILURE (0)

Anonymous Coward | more than 2 years ago | (#37528240)

No, it looks exactly like 262 GIGABYTE and 256 GIBIBYTE

Re:FAIL AT FIXING IS FAILURE (1)

Anonymous Coward | more than 2 years ago | (#37529212)

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:Does that make any sense? (0)

Anonymous Coward | more than 2 years ago | (#37528390)

Oh noes, did you call Seagate too?

"Manufacturers are stealing 24 bytes from every kilobyte!" Say it ain't so!

Re:Does that make any sense? (1)

blue_teeth (83171) | more than 2 years ago | (#37529236)

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? (1)

davecb (6526) | more than 2 years ago | (#37526704)

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

--dave

Re:Does that make any sense? (1)

aglider (2435074) | more than 2 years ago | (#37526874)

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.

Re:Does that make any sense? (1)

Anonymous Coward | more than 2 years ago | (#37528932)

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.

price? (1)

dutchwhizzman (817898) | more than 2 years ago | (#37525586)

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.

Re:price? (1)

backslashdot (95548) | more than 2 years ago | (#37525708)

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? (0)

Anonymous Coward | more than 2 years ago | (#37528832)

nice touch.

Re:price? (1)

eclectus (209883) | more than 2 years ago | (#37526024)

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.

Re:price? (1)

TheSunborn (68004) | more than 2 years ago | (#37526888)

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? (0)

Anonymous Coward | more than 2 years ago | (#37528282)

I would love to lose 256 machines all at the same time. That is something my boss would say. "Just buy 1 really big box and put everything on it. Think of the money we could save in infrastructure costs." I stand in amazement at times that he is a director. damn...

Re:price? (0)

Anonymous Coward | more than 2 years ago | (#37526366)

8-core intels isn't the same market segment, while a single-socket (8 cores, 64 threads) may or may not compete on price/perf (it comes down to what the perf difference is between 16 intel threads and 64 T4 threads), a fully decked (4-socket, 32-core, 256 threads) traditionally beats out it's throughput equivalent x86 counterpart on price/perf by a wide margin, and it always beats out the equivalent x86 cluster (fewer nodes -> less memory and disk overall, which adds up to a lot more than the rest of the hardware, especially on larger scale DBMS applications where you're pushing tables out into memory).

But hey, if all you need is 8 cores and 16 threads, it doesn;t make much sense to buy a 64 core and 256 thread system, unless you know you'll need to scale to that kind of throughput, it'll cost less and offer better perf (interconnects ftl) to keep adding in T4s as you need them, than to add nodes to a cluster (again, memory, storage, etc) the initial cost is higher, but the long term cost of expansion is much lower.

Keep in mind also, that if you're running Oracle EE, the per-socket licensing cost significantly less of a 1-4 socket T4 server, whereas it will kill you on the throughput equivalent x86 installation. (and before anyone rags on Oracle for the per-socket licensing, RHEL does that, too). There's also one of the main reasons Oracle acquired Sun in the first place (to be able to provide the entire stack top to bottom from a single vendor, like IBM does) to consider, if you buy your hardware from a vendor, if they offer the option, you'd be more inclined to equire the rest of your stack from them too, you're already saving on Oracle EE, but you're also saving a bundle on the OS, Oracle offers both Solaris and Oracle Linux for a flat rate of $2499 per machine, which gets you all of one socket from Red Hat, plus you save on support.

People are a little baffled at why Oracle didn't opt to double the core count or thread count as the Niagara line of processors has in the past, but it's because Sparc is still the most paralell CPU of its class CoolThreads kills Hyperthreading and doubles Power and Itanium in that regard, what hurt the Niagara processors was that while there were more threads to work with, the threads were slow enough that Xeons would win out on occasion by having few, but faster (by a factor of two) threads than the 1.6ghz Niagaras, now the threads are nearly twice as fast as before, and that's four times as many as on a Xeon, which brings it level with the Power CPUs (which have up to nearly twice the clock, but half the threads)

Re:price? (1)

Bengie (1121981) | more than 2 years ago | (#37527492)

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.

Price? (0)

Anonymous Coward | more than 2 years ago | (#37525646)

Does anyone know the price range of a 1 to 2 CPU server for the new T4 chip?

But - (1)

Anonymous Coward | more than 2 years ago | (#37525676)

Will it run Linux?

Re:But - (1)

xmorg (718633) | more than 2 years ago | (#37525902)

No, but it runs FreeBSD

Re:But - (0)

Anonymous Coward | more than 2 years ago | (#37526642)

Why would you want to run a kiddie O.S.? Linux is total crap.

Re:But - (1)

unixisc (2429386) | more than 2 years ago | (#37526930)

Sparc runs several Linux distros, such as RHEL, Debian, and also the 3 major BSD ones - OpenBSD, NetBSD and FreeBSD. I see no reason why T4 shouldn't. What I do wonder is - does Oracle offer Oracle Linux as an option on Sparc h/w?

Re:But - (0)

Anonymous Coward | more than 2 years ago | (#37529394)

SPARC is officially supported by the Linux kernel, but it's not a mainstream platform. Red Hat does not produce a SPARC version of RHEL.

Nobody (well, maybe a few people with specialized goals/needs) goes out to buy an expensive SPARC box to run Linux on. There is for all practical purposes zero consumer interest in that combination.

The only commercialized SPARC Linux distro I can think of is Wind River; Wind River is popular with the embedded/telecom space where Linux has an edge in features (and Sun/Oracle has an edge in NEBS-compliant hardware, i.e. Netra SPARC servers)

Otherwise... If you're buying SPARC gear, you're going to want to run Solaris on that. It's optimized for the hardware Sun/Oracle sells, tested on the same hardware, and frankly, it's a superior OS.

Amusing. (0)

Anonymous Coward | more than 2 years ago | (#37525748)

I always find it so amusing to see the same people that are always raving about how great it is to have AMD competing against Intel, how everything needs to be ported to ARM for competition, saying "SPARC should go away and we should just stick to Intel". Huh? Do you want competition or not?

Pricing? No, *licensing* (2)

Brandon Hume (73471) | more than 2 years ago | (#37525780)

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.

Re:Pricing? No, *licensing* (1)

angel'o'sphere (80593) | more than 2 years ago | (#37526178)

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.

Re:Pricing? No, *licensing* (0)

Anonymous Coward | more than 2 years ago | (#37527432)

> DBs are no longer I/O-bound since typical querries return
> gigabytes of results that need to be joined and ordered.

What?! Either you're incompetent or your place of business is highly atypical, or perhaps both.

Re:Pricing? No, *licensing* (1)

Bigbutt (65939) | more than 2 years ago | (#37526230)

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]

Re:Pricing? No, *licensing* (0)

Anonymous Coward | more than 2 years ago | (#37527018)

Why in the world would you move from oracle -> mysql when oracle -> postgresql is so much easier? You can even buy support from a company at a tiny fraction of the cost of oracle that will give you near perfect pl/sql compatibility in postgresql, with support. Oracle is even crippling mysql now, it really makes no sense at all to move to it from an Oracle DB.

Re:Pricing? No, *licensing* (1)

Bigbutt (65939) | more than 2 years ago | (#37527712)

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

[John]

Re:Pricing? No, *licensing* (1)

hattig (47930) | more than 2 years ago | (#37526970)

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.

They've made Itanium! (0)

Anonymous Coward | more than 2 years ago | (#37525876)

Itanium worked out well enough for Intel. Good luck with your version Oracle!

Cores? (1)

Bigbutt (65939) | more than 2 years ago | (#37526198)

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]

I'm not dead yet (1)

mevets (322601) | more than 2 years ago | (#37526400)

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.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...