Sun, Fujitsu crank Sparc64-VII clocks

5%?? Quad core took away 30% of the core performance

I will never buy a Fujitsu SPARC64 system. The processors had poor performance before they went quad core. Sun's Mvalues show a stunning 30% drop in performance per core.

It looks like Oracle is in no mood to decrease the core factor pricing either. Larry would not even reduce the T2's only the latest T2+.

I am looking for a good DB2 sales person to brain wash my DBA's

Oracle purchasing expert..

RE:hmm....

It's very simple. Lack of product development, that actually get products out on the marked.

// Jesper

RE: But what compilers were you using?

".... Generic SPARC code will not take advantage of the new features of the processor. Currently, only the Sun Studio 12 update 1 compilers (C/C++/Fortran) will generate optimal code for SPARC64 VII. (And they're a free download)...."

Oh, so the old Sunshine about binary compatibility between SPARC generations is still true, you just lose 30% performance when you run an old binary on new cores unless you completely recompile it with new compilers? Hmmmm, another "seamless" SPARC upgrade experience - not! Not much of an incentive to buy new SPARCVII! If you're going to have to recompile anyway, you're probably better off migrating off SPARC onto a platform with a future and do your recompile there.

/SP&L

Perceived value

A a SPARC VII customer I can say I've been pleased with the systems. In real world application performance (mostly running oracle) our M4000's have delievered the goods. The x64 servers give much better price/performance, but we're not just interested in price performance. The RAS of the system is very important to us. Considering the RAS of the platform and real world application performance I think the SPARC VII systems give good value vs. Power and Itanium machines. If you compare SPARC VII to x64 and you're looking for trans per $ the x64 will win. Its way cheaper and the performance just as fast at <65% utilization. When you buy these RISC systems you have to consider you're motivations. Are you just looking for $ per tran or are you concerned about RAS? How much is that RAS worth to you?

@Matt Bryant -- RE: But what compilers were you using?

~ so the old Sunshine about binary compatibility between SPARC generations is still true, you just lose 30% performance when you run an old binary on new cores unless you completely recompile it with new compilers?

this has typically been the case with intel chips - except a recompile did not typically help you under intel

as an example, moving from dual to quad to hex core in the same family of chips saw a loss in performance on a per core basis with intel.

adding the new cores under intel gave an extra throughput boost, though

RE: @Matt Bryant -- RE: But what compilers were you using?

"....this has typically been the case with intel chips...." Sorry, but that's complete male bovine manure.

RE: @Matt Bryant -- RE: But what compilers were you using?

Matt Bryant posts, "...between SPARC generations is still true, you just lose 30% performance when you run an old binary on new cores unless..."

Anonymous posts, "this has typically been the case with intel chips"

Matt Bryant posts, "Sorry, but that's complete male bovine manure."

http://www.intel.com/technology/advanced_comm/multicore.htm

"...each execution core in an Intel multi-core processor is clocked slower than a single-core processor..."

While Anonymous Coward did not cite external data, he seems to know more than you on this topic.

This has been a well known fact in the computer industry for many years. The addition of more Intel cores helps to increase overall throughput, to compensate for the decrease in core clock rate with Intel.

It has more to do with thermal envelopes & physics than "male bovine manure".

A neat new feature in the latest Intel processors try to mitigate the problem and provide short clock rate boosts to busy cores when other cores are idle. Intel can be pretty creative, sometimes!

Matt Bryant doesn't understand multi core technology! HA HA HA HA!

n00b matt troll bryant @16:21

--- "....this has typically been the case with intel chips...." Sorry, but that's complete male bovine manure.

http://redmondmag.com/articles/2008/05/01/the-multicore-muddle.aspx

--- In fact, the cores in today's multi-cores generally run more slowly gigahertz-wise than advanced single-core processors. Unfortunately, many Windows-based applications are built serially with a single processor in mind. When run on multi-core systems, often the extra cores are doing little to nothing.

poor n00b matt troll bryant - intel chips lose per-core performance in multi-core chips - duh!!!! better get your mommy to teach you the facts of life!

RE: Matt Bryant doesn't understand multi core technology! HA HA HA HA!

Oh yeah? So where's the bit that says the Intel cores go 30% slower then, you moron? Oh, it doesn't. Try reading, noob.

Broken Record

I'm beginning to think that Kebbabert is an automated program that runs whenever MB spouts some stuff at SUN. I've seen this response sooo many times its getting boring

STOP,...well please stop..the pair of you

re: Matt Bryant

Ha Ha! Matt's been panced. No one to come to Matts defense? What a n00b!

Matt Bryant doesn't understand multi core technology! HA HA HA HA! #

Matt Bryant posts, "...between SPARC generations is still true, you just lose 30% performance when you run an old binary on new cores unless..."

Anonymous 1 posts, "this has typically been the case with intel chips"

Matt Bryant posts, "Sorry, but that's complete male bovine manure."

David Halko cites Intel web site which explains Intel muti-core technology, "...each execution core in an Intel multi-core processor is clocked slower than a single-core processor..."

Anonymous 2 cites Redmond Magazine article explains, "In fact, the cores in today's multi-cores generally run more slowly gigahertz-wise than advanced single-core processors. Unfortunately, many Windows-based applications are built serially with..."

Anonymous 3 posts, "poor n00b matt troll bryant - intel chips lose per-core performance in multi-core chips - duh!!!! better get your mommy to teach you the facts of life!"

Matt Bryant responds to Anonymous 3 with, "Oh yeah? So where's the bit that says the Intel cores go 30% slower then, you moron?"

It seems Matt Bryant finally passively concedes with Intel technical article and Microsoft advocate magazine that Intel core in multi-core's are slower than the single core performance. The only question is now percentage.

Matt suggested the 30% decline in performance associated with SPARC when running SPARC software on new cores. Can you find a SPARC (or SPARC64) web site (i.e. Sun or Fujitsu) and a Solaris advocate publication that suggests a SPARC core from a multi-core chip is 30% slower "when you run an old binary on new cores", related to the SPARC64 processor, which was the object of the article and comment you targeted?

Ball is in your court... give the reader something reasonable to consider your original speculation.

RE: Assorted Sunshiners

I'm not surprised at your desperate attempts to deflect the conversation away from the poor SPARC64 roadmap. After all, such attempts were common during the UltraSPARC years, and your flat-out denials of any problems with Rock were, frankly, hilarious.

RE: Kebabfart

All you have proven is you need to go back to a proper uni to get a real computing degree, and then some real industry experience. Don't bother coming back until you have at least one or the other, preferrably both. Once you have achieved something you are then welcome to come back and partake in future discusssions. Until then you are just wasting electricity.

RE: Billl

Your remarks are typical of Sunshiner fare, offering nothing of technical value and displaying the same, repetitve lack of originality. Unlike you Sunshiners, that have to huddle together due to your herd metality, I really don't need anyone to help me show you up for the dribblers you are. Your post doesn't actually need a reposte as it gives a clear insight into both your lack of knowledge or eloquence, and that you would rather bash at a critic as you are unable to provide a reasoned, technical argument to counter.

RE: Novatose

Whilst I'm pleased to note the death of Rock seems to have led you to toning down your rabidity, you still fail to read other posts before sticking both feet so firmly in your own mouth (which must be quite a trick when your head has spent so long up McNeedy's rectum). If you had read the original post by an AC, Tuesday 13th October 2009 17:53 GMT; "....Sun's Mvalues show a stunning 30% drop in performance per core....." So, is Sun's own technical reference (which I'm sure paints as rosey a picture as possible) not good enough for you? Think carefully before you next assault your keyboard.

/The laughs just never end with this lot!

RE: @Adam 61

Kebabfart, you really need to take a look at Novatose's posts. Not becasue they are brimming with genius, but because he at least tries to deflect with what is the closest you Sunshiners come to subtlety. He has also started to know when to stop flogging a dead horse. You, however, just don't realise when you have lost, and that people are just laughing at you.

In my opinion, the current Niagara CPUs have too little cache, and I believe it adversely affects their performance. But then the whole basis of the Niagara design is to accept failure and try and alleviate the issue by queuing up lots of failure and pretending the really slow completion time is made up for by having lots of really slow completions finally happen, as long as your app supports multi-threading. Response time not an issue for you? We have been over all this before, please try and concentrate, read and then move on.

Let's re-cap for Kebabfart - the conversation has taken the route of wondering whether the drop in performance between dual- and multicore Sun chips is excessive compared to other CPUs. Now, do you have anything to actually add to the discussion, or can we hope you're busy filling out your UCAS application?

/SP&L

mattie's opinions matter little in the real world until he provides references

--- mattie - In my opinion, the current Niagara CPUs have too little cache, and I believe it adversely affects their performance.

the execution pipes remain full under load, there is probably no higher performing core on the market that remains active running instructions as a fully loaded niagra core.

--- mattie - Response time not an issue for you?

nope, response time has never been an issue for me with niagra. response time has been great for my applications. it seems the TPC-C benchmark showed better response times under heavy load than IBM POWER.

i like david halko's approach - show us a url to a real world application benchmark where niagra had poor response time in comparison to another. what do u have?

we are still waiting for a url to a 30% slower SPARC binaries on new cores, an anonymous posting about something that may or may not be in a document is not a reference. what do u have?

RE: mattie's opinions matter little in the real world until he provides references

"....the execution pipes remain full under load, there is probably no higher performing core on the market that remains active running instructions as a fully loaded niagra core....." That's a bit like comparing a load of ants to a gardener. The gardener digs up a plant in one, moves it, then looks for the next plant. The ants chop the plant up into bits and then move it all in bits. Sure, the ants look busier because it's the only way they can handle the load, but the gardener is done before the ants, and his plant is actually likely to be in the state you wanted. Simply trying to tell us that because Niagara's cores "remain active" somehow makes it better is a joke - the whole design is based on queuing up stalled transactions!

"....nope, response time has never been an issue for me with niagra...." Well it is for me for the business applications we run, and we run a pretty-much generic stack of apps like Oracle DB, WebLogic and some other off-the-shelf apps. In our testing, with our data, Niagara was slowest by a country mile. All those apps perform well on real enterprise CPU designs like Power and Itanium (or SPARC64) because they have heavy, often single, threads. And no, I am not at liberty to post my company's private reports.

You may also want to consider customers looking at trading systems (hmmm, might be slightly time-dependent, don't you think?). Can you post info on any trading system anywhere running on Niagara? I seriosuly doubt it. And anyone running a development of an older, monolithic system, especially those with large and busy databases, is not going to like the idea they have to totally redesign and recompile their app stack to get the best out of Niagara, which I guesstimate covers about 90% of the existing enterprise UNIX base. If that wasn't the truth then Snoreacle wouldn't need the Fujitsu SPARC64s this thread was originally about, before Kebabfart and fellow Sunshiners started their usual and boringly repetitive cheerleading routine for Niagara. And yes, it may be a bit condescending to say, but cheerleaders is such an apt description of Kebabfart and co given that cheerleaders are often just noisy air-heads.

"....show us a url to a real world application benchmark where niagra had poor response time in comparison to another. what do u have?..." Well, as I said before, I didn't even bring it into the conversation in the first place (what, can't any of you Sunshiners read and COMPREHEND?), but I'd have thought a Sunshiner like yourself is bound to have Sun's own Mvalues to hand. If not, then tough - the Sun Mvalues are NDA from Sun, as you no doubt know, so I can't post a link to them. Now, I wonder why Sun would want to keep Mvalues out of the hands of the general, buying public....

But, I can post the following link; http://www.sun.com/servers/coolthreads/overview/products.jsp. That's the Sun Niagara servers page. It used to admit all the CMT servers were just for web and edge apps, but Sun have updated it to amusingly add ERP, SRM and CRM for the T5440. Probably becasue they got told how silly they looked trying to sell T2/T2+ as enterprise systems when their own webpage said they weren't suitable. Please note that even the Sun marketting folks draw the line at trying to pretend the other Niagara systems are anything other than webservers. Then you could look at the Performance page (http://www.sun.com/servers/coolthreads/overview/performance.jsp), where Sun posts their very thin benchmark comparisons - all Java. Yes, like my enterprise billing systems is written in Java - not! The problems with integer and floating point performance are carefully hidden away here, but then Sun wouldn't be doing a good job if they were admitting their designs' weaknesses. All vendors highlight their carefully crafted results and all of them will tell you that on such-and-such an app they are the best, but the reality is that means nothing until you get the kit into your own environment and run it with your stack and your own data. Until then, selective benchmarks are, at best, mere indicators.

But, if you want to compare benchmarks, we can have some fun. After all, we've been here before with Novatose's cherry-picked SAP benchmark results (http://www.theregister.co.uk/2009/02/27/hp_sun_oem_comment/comments/), do you really want to be shown up again?

/SP&L

RE: Dumbest thing Ive heard in a while

"Dumbest thing Ive heard in a while..." Really, you heard it? Was that because you had to get someone to read it out for you, just so you didn't get stuck on the long words?

"....if the Niagara has too little cache or not, IS NOT AN OPINION!...." Erm.... actually, that is an opinion. I expressly stated that it was my opinion. Would you like me to post the dictionary definition of an opinion? I'm guessing that amazing continental Maths degree you went on didn't include a module on written English.

Reading through the rest.... bla, bla, bla, no technical argument at all, bla, bla, bla....

Are we back to the funny benchmark comparisons again? OK, let's consider a Transit van versus an articulated lorry. The Transit van accellerates faster, has a smaller turning circle, does more mile to the gallon, and can probably get across town faster than the artic. Sounds good, doesn't it? But, when it comes to moving those big loads nationally or even internationally, companies go and buy articulated lorries for the job, because the reality is the artics are the better tool for the job than Transits for long distance haulage. Now, benchmarks are chosen to make a server look better, in isolation they only tell you about one narrow facet of performance in a very carefully constructed test (think TPC-C here). In some situations, a Transit is a better option than an artic. But to look at one or two factors, such as turning circle or economy, and then try and claim your solution beats all others regardless is naive. The reality is enterprises need the equivalent of articulated lorries (Itanium, Power and SPARC64) for the current range of apps, and though they may also make use of Transits (Xeon, Opteron and Niagara) for lighter tasks they are not going to replace their artic fleets with Transits. So, unless your business requirement is doing exactly what Snoreacle did in their TPC-C benchmark session (and please do name me a business that does nothing but run that Sun TPC-C setup all day, every day, as a business), you're much better off ignoring the TPC-C result and instead doing a proof-of-concept, in your own environment, with your own data, as that's the only real test that counts.

"....Ive heard that you need an IQ of at least 70 to be able to breath on your own." Oh dear, more of other people doing the reading for you? I'm beginning to wonder if you actually do any reading or research of your own or whether you just repeat whatever other people tell you. Breathing is an autonomic reflex, that is it operates below the level of conciousness, and your IQ has no effect on your basic ability to breathe. Whilst you can exercise voluntary control over your breathing (such as holding your breath), if you don't conciously think about it then you still carry on breathing (like when you are asleep). You can suffer complete brain death in the areas of the brain that deal with concious problem-solving, the bits that count towards your IQ, and still carry on breathing because the control is run subconciously from the brain stem, namely from the the medulla oblongata and the pons (you may need someone to read up on those for you). I'm not an expert on the autonomic nervous system and exactly how it works, but I suggest you steer clear of the topic as it will only make people laugh at you all the harder.

/while kebabfart!=0 do; until ribs=aching do point laugh; end; end.

RE: @Moron

Aw, don't go calling yourself that, you'll give yourself a complex to go along with those other ones you so obviously already have!

"....Look, you can not claim that "in my opinion that 2m guy is shorter than the 1.5m guy". The hard facts shows, the metric shows that the 2m guy is... 0.5m taller!...." Which completely misses the whole point. What I'm trying to explain to you in the simplest terms is that the tallness aspect only applies to cases where tallness is relevant. If your problem is "I need someone 2m tall to reach a high shelf" then your case holds. If, however, your problem is "I have a Formula 1 car and I need my driver to be as small and light as possible", then the shorter guy is going to have an advantage. Simply stating "my guy is taller therefore he is better for ALL tasks" is simply.... well, moronic. The problem with all the benchamrks you quote are they are carefully constructed incidences, which bear no relation to what really happens in business. That's why I advocate shoot-outs or at least proof-of-concepts, in your own environment, with your own data. For you to recommend selection just going on vendor's benchmarks alone simply exposes your lack of experience.

"....The Niagara is slow on few threads and small loads. But it absolutely beats the shit out of anything when it comes to big loads, thanks to it's many threads...." No i doesn't, it only does when the threads are small. And the bigger problem for you is that the majority of today's business applications don't work they way Niagara wants them to, and it is always easier for companies to change the platform than the app.

"....The 5GHz Power6 is like a fast Porsche, able to transport 2 persons very fast, in 10 minutes. And the 1.4GHz Niagara is like a large slow bus able to transport 100 persons, in 30 minutes....." No, the Niagara is more like a toy bus with tiny seats that can only transport midgets, and when you try and squeaze normal-sized adults (heavy threads) onto the toy bus it just can't take them. And Power's or Itanium's superior bandwidth to cache, memory and I/O (let alone just having more cache), mean they are the buses, and Niagara is more of a fleet of toy peddle-cars strapped together. And then there is the matter of scale - Power and Itanium scale up to many buses working together seamlessly. But when Niagara has a few peddle-cars strapped together you hit the socket limit of the design, and then you have to go start a new bunch of peddle-cars and get extra software to make them work together with the first set, and that clustering software doesn't scale either, so in the end you throw away the peddle-cars and move to the real Sun bus, the Mseries (after a recompile, and you still don't get the performance of Power or Itanium).

".....Regarding that you need 70 IQ to be able to breath, well as I said - that was something Ive HEARD. Maybe it was wrong. So what? Ive HEARD it. I do not claim it to be true." Well, Kebabfart, the problem for you is most of the junk you post here as "the truth" comes across as stuff "you have heard" and not experienced, so everyone is not just going to know you don't have any experiences of your own, but also assume you don't know how to fact-check what other people are telling you. Why should we believe anything you say, Mr Gullible?

/SP&L

Matt Bryant - RE: Dumbest thing Ive heard in a while

Matt Bryant barks - I'm guessing that amazing continental Maths degree you went on didn't include a module on written English.

This is coming from the illiterate who can't spell Solaris! ROTFL!

RE: mattie's opinions matter little in the real world until he provides references #

Matt Bryant posts, "the majority of today's business applications don't work they way Niagara wants them to"

A couple dozen says otherwise:

http://blogs.sun.com/BestPerf/entry/bestperf_index_14_october_2009

Care to show us a reference to a couple benchmarks? ;-)

Matt Bryant posts, "if you want to compare benchmarks, we can have some fun. After all, we've been here before with Novatose's cherry-picked SAP benchmark results"

No one named Novatose posted the benchmark. You incorrectly accused someone else of posting that benchmark, too. You couldn't understand that Sun ran the newer, more CPU intensive, Unicode benchmark when you compared that score to the older, less CPU intensive, non-Unicode benchmark.

;-)

RE: Mattie Pattie Laddie

Kebabfart, simply repeating the same flawed analogy over and over is not going to convince anyone that you are capable of reasoned and original thought.

"....Regarding the IQ. I have only heard it. I dont claim it to be true." Which begs the question what of the "information" you post about Sun is actually of your own experience, or if it has all simply been "heard" from others? Just to clarify things for us, please let us know when you have run anything on a T2 or T2+ system, what you ran, what storage it was connected to, and if it was configured at all like the Sun TPC-C build. Then please do the same for your experiences with Power, Itanium, Xeon and Opteron.

/very concious of the word count - was that OK, Ms Bee?