While Sun Microsystems has been muzzled by Oracle to not talk in specifics about the future of the Sparc server line, Sun and its server partner, Fujitsu, can nonetheless keep enhancing their jointly sold midrange and high-end server Sparc Enterprise machines, and at the OpenWorld customer event in San Francisco this morning, …
in recent tests I did for a client these got soundly thrashed by two year old Intel based kit running Red Hat.
I say sadly because I began my carrier with Sun and felt they had so much potential.
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..
But what compilers were you using?
You can't expect best performance on these things unless you are using a compiler that optimizes the generated code for the specific runtime processor. 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)
Always one to look at other architectures, what specifically is the problem with the sparcs with regard to the stated problem of performance compared intel stuff?
Is it something intrinsic to the actual cpu?
or is it more to do with the supporting stuff ie not being able to handle bandwidth?
or is it a question of code?
It's SPARC not Sparc
By the way, SPARC is a trade marked acryonym, all caps please.
@ AC Sadly #
Re: "in recent tests I did for a client these got soundly thrashed by two year old Intel based kit running Red Hat" No you didn’t and comments like this only get you 'mod' points on Slashdot along with BS like " I recently migrated a 10,000 Sun enterprise to Red Hat ............."
Good luck with your "carrier"
It's very simple. Lack of product development, that actually get products out on the marked.
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.
sT0rNG b4R3 duRiD posted, "Always one to look at other architectures, what specifically is the problem with the sparcs with regard to the stated problem of performance compared intel stuff? Is it something intrinsic to the actual cpu? or is it more to do with the supporting stuff ie not being able to handle bandwidth? or is it a question of code?"
Actually, there in no problem with the SPARC architecture. People are just not that familiar with how computers work.
Every CPU architecture from every vendor has optimizations where some code will run faster than other code, depending on which platform compiler optimizations were done. It just happens to be that sometimes, unqualified people are doing the comparisons.
For example, you may get significant difference in performance against Intel chips, depending on the family of Intel chip, due to their optimizations.
The compiler knows the chip, cache, instruction sets, and nuances in the pipelines - and when code is compiled for the correct family, the resulting code will run optimized.
This is the same for every computing architecture and every operating system, from the beginning of time, including Intel and Linux.
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."
"...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.
--- 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.
Mattie Pattie Nobbie
Just quit it. You have proven numerous times you know nothing about CPUs. Do you still claim that the Niagara suffers from a too small a cache, despite me explaining too you umpteen times that Niagara doesnt need a large cache? Shall we continue with that discussion about Niagaras cache, or have you at last understood?
So, tell me again why the Niagara is so slow and why it suffers from a too small cache. And motivate thoroughly. And explain why the Power6 is faster than the Niagara on server work loads, where the work load dont fit into Power6 cache so the Power6 cache starts to thrash, swapping data in and out all the time. Go ahead.
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.
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.
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.
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!
And you blame ME for being boring and sounding like a broken record??? What small weird mushrooms have you eaten lately?
Have you never wondered why I write that over and over again? No? I thought so. I can explain to you that Mattie Pattie Laddie has not yet understood the Niagara and he still thinks it suffers from a small cache. Until he understands, I will continue lecture him. I agree he has a very thick forehead, and it takes lots of time to reach his brain, but I will succeseed. I am not the one who turns away from impossible missions!
So I suggest you tell Mattie Pattie Laddie to stop being so boring and stop sounding like a broken record. Until then, you will read my reaction on his action, here. I just react on Mattie Pattie.
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?
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?
Dumbest thing Ive heard in a while
"In my opinion, the current Niagara CPUs have too little cache, and I believe it adversely affects their performance."
Seriously, this must be the dumbest thing you ever posted. I mean it. Why? Now I motivate why.
Anyway, if the Niagara has too little cache or not, IS NOT AN OPINION! What does benches and real life say? If the 1.4GHz Niagara beats the shit out of 5GHz CPUs, then how the hell can your opinion be that the Niagara suffer from a too small cache??? It is like saying to the fastest car in the world "in my opinion Niagara car is not fast. I admit there are no faster cars, and the Power6 car is slower in several benches, but in my opinion Niagara car is slower". If the Niagara car scores higher, it is not an question of an opinion. If one guy lifts 100kg and the other guy lifts 50kg, then you can not say that "in my opinion the first guy is weaker, I admit that hard benchmarks show that the first guy lifts more, but in my opinion the first guy is weaker". You also say about a man that is 2meter long "in my opinion he is shorter than that 1.70meter guy", yes?
Is this dumb or is is just dumb? Seriously, this must be the dumbest thing Ive heard in a while. I mean it. "in my opinion...". Jesus. I almost dont know what to say. Mattie Pattie Laddie, do you have a large machine connected to you, saying beep, beeep and wosh wosh every ten second or so?
Ive heard that you need an IQ of at least 70 to be able to breath on your own.
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.
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! You can not argue against metrics and hard facts! You can not have an opinion contradicting the metric, unless you are a true moron. "I see that you have truly black hair, but in my opinion you are blonde"???
Regarding your car analogy, I totally agree with you. 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. 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.
Now I ask you; which choice is the best to transport 10.000 persons? For small loads, the Porsche is clearly fastest. For large loads the Niagara finishes first, despite being slower than the Porsche. It is a fact that the Niagara has many threads, and it is a fact that the Power6 has few threads. And ergo, the Niagara wins for large loads. It's throughput is extreme.
Therefore, for small loads, single threaded things, use the Power6. For large loads, where extreme throughput is needed, use the Niagara. The niagara is slow on single threaded things, everyone knows that. SUN says so, too.
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.
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?
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:
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.
Mattie Pattie Laddie
Look, if Niagara would indeed suffer from a small cache, then it would show in it's performance. It would be slow and it wouldnt be able to take many world records, nor beat IBM Power6 cpu. But hard facts tell that Niagara is extremely fast on some work loads, it is fastest in the world. So how can it be your opinion that the Niagara is slow then and suffers from a small cache? If a guy is tallest in the world, beating everyone else, do you claim that "in my opinion he is short"? Could you please explain this?
Regarding the car analogy, the Niagara is slow on single threaded loads. But it has many threads. Whereas the Power6 has few, fast threads. This means that Niagara can handle large loads with many threads, whereas Power6 can not. Power6 is like a Porsche, able to transport 2 persons fast, in 10 minutes. The Niagara is like a slow bus, able to transport 100 persons in 30 minutes. Which one do you think will transport 10,000 persons fastest? This is also confirmed by the benches.
Regarding the IQ. I have only heard it. I dont claim it to be true.
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?
Mattie Pattie Laddie
When I say "Ive heard that you need an IQ of 70 to be able to breath", you can not compare it to when I claim the Niagara does not suffer from a small cache and therefore it is slow. Because, regarding Niagara, I have read articles, and I know CPU architecture and computer hardware architecture. I even have one of my M Sc in that subject! Regarding nervous systems, I dont know anything, I dont have a degree in it, I have not studied it. It is a big difference if you hear something from a random guy, or if you have studied articles and have a M Sc degree.
But maybe you fail to see the difference? Maybe that explains why you can claim something weird as "in my opinion the niagara suffers from a small cache" - when at the same time, it's design is from a theoretical view point superior to legacy constructed CPUs as Power6 which needs to fit the work load into it's cache. And also, the benches and real life testimonies show Niagara is extremely fast on certain work loads. So how can it be so fast, if it supposedly suffers from a small cache? Can you answer me that? You dont see the discrepancy? You claim it is slow, but benches and hard numbers and theoretical investigations prove the opposite. You dont think at all? Not very academic, eh?
- NASA boffin: RIDDLE of odd BULGE FOUND on MOON is SOLVED
- Pic Mars rover 2020: Oxygen generation and 6 more amazing experiments
- Microsoft's Euro cloud darkens: US FEDS can dig into foreign servers
- Plug and PREY: Hackers reprogram USB drives to silently infect PCs
- Boffins spot weirder quantum capers as neutrons take the high road, spin takes the low