New IBM POWER8 CPU

Status
Not open for further replies.
mikeblas said:
I guess the problem is that I have a more practical definition of superiority.

Your car has an ECU on it which controls engine function. That ECU contains a computer which listens to sensors, makes some decisions, and controls the engine. That ECU can't emulate a large computing cluster, but the large computing cluster can certainly emulate the ECU.

Is the ECU superior to the computing cluster? It certainly is: nobody wants to buy a car that requires a genset to run a computing cluster that weighs a few orders of magnitude more than the car itself.

I might not argue that the cluster is more capable in most respects, but even then it's not capable of being portable or running in constrained heat or power environments. Things like capability and superiority are situational, not absolute; a fact that makes your comparisons of minicomputers to mainframes very brittle.
Click to expand...
We talked about performance, right? Which cpu/server is the fastest. We did not talk about if a computer is portable. In the performance arena, which we talked about, a computer that can emulate another sufficiently enough (but not the other way around) is faster - and therefore better.

Sure, if you talk about minimialistic and portable computers then there is another discussion. But we talk about best performance. So your example is flawed.


I never said that bloat wasn't a bad thing. I just said that you're wrong in claiming that all developers try to actively refactor code; and that you're wrong when you claim smaller code is always better; and that you're wrong in your belief that minimization is most important.
Click to expand...
All serious developers aim to write beautiful code, small and efficent. Lean and mean. If you dont know this, you have not programmed a lot, nor talked to developers that care about programming.

Have you heard about Einsteins saying: "perfection is not achieved when you have nothing left to add, but when you have nothing left to take away".

Churchill said once "I am short on time, so my letter will be long. I dont have time to write short". If you are going to aim only for the most important and delete unnecessary cruft, you need to think a lot and reformulate again and again. Anyone who wrote their thesis or research papers knows this. Any fool can add functionality, but it takes much effort and brain power to create something minimalistic, that only contains the important stuff. The essence.

For instance, in designing the Go language, they designers tried to create a minimalistic language with no unnecessary features. They followed the KISS-principle. Creators of Unix, C and Plan9, etc is behind Go. Real old gurus with big beards.

There is another book, "Coders at work" by Seibel. In that book he has lengthy interviews of several hacker stars, such as Guy Steele, Ken, Don Knuth, etc. In almost every interview they talk about how code should be small and beautiful, only contain the essential.

Serious coders think like that. Just read that book and see it yourself. Educate yourself about programming.
 
mikeblas said:
You're asking about code size, but I think brutalizer is making claims about code complexity.

Code size matters at a small level. Larger code runs slower when it starts to not fit in cache. OTOH, larger code might be faster becasue it accesses memory less, implements a more efficient algorithm, or offers more features.

Some of those changes also involve (or, at least, imply) adding complexity. While we measure code size in bytes (or maybe lines of code), there's no real concensus about how to measure complexity, so comparisons of complexity are harder than comparisons of size. More complex code is better when the complexity is required, and worse when the complexity is arbitrary or not required.

Claims like "The difference between an experience programmer and a beginner, is that the experienced will use much less code to do the same thing as the beginner" or "All developers tries to refactor the code to make it smaller whenever they can" simply don't reflect the reality of commercial software development.
Click to expand...
I agree with the last paragraph, in commercial software development the developers might not have time to refactor the code. But every programmer worth their salt, AIMS for beautiful and lean mean code. Time constraints might hinder this. Many coders feel bad for haved checked in bloated and bad code. They are not proud of the code, and wished it would be neater and more elegant. They did a bad job (beacuse of time constraints or whatever), and EVERYONE wants to do a good job.
 
jimmyb said:
It is a *general* principle. That means you can't use it to back *specific* claims and comparisons about hardware.

You made a claim about how legacy instruction support was significantly slowing down mainframe and x86 CPUs. "Bloat" is not an argument. There are thousands of engineers doing actual analysis and research on CPU design and verification, and they aren't basing their arguments solely (or even substantially) on the concept of bloat.
Click to expand...
As I said, unnecessary transistors make the circuit more complex, it uses more power, chances for bugs are higher, more resources are used (smaller cpus have higher yield on the wafers), etc - the reasons are numerous to try to reduce the nr of transistors. There are several software systems that try to reduce the nr of transistors on the market - why if no one cares about bloat? There are many researchers trying to reduce the nr of transistors in circuit complexity, as I have showed links - why, if no one cares?

Your comment about math is dead wrong, so why would not this comment be dead wrong too? I know math, but dont know about cpu design, but common sense say they too try to reduce size of their products (software systems on the market tries to reduce nr of transistors, researchers focus on this, keep power down, complexity down, etc)
 
Anyway, shall we go back to IBM's cpu discussion? And why the POWER8 is much faster than the Mainframe cpus? And that the Mainframe cpus have failed miserably, because they are much slower than a decent x86 cpu, and uses way more cache?

Earlier I claimed that Mainframe CPUs use very much cache, somewhere around 250 MB cache or so. And people said I was wrong on this. But here is proof, the link I read. Can someone interpret this for me? Can someone confirm I was right all the time?

brutalizer said:
I talked about reading a link about Mainframe cpus using lot of cache, I stumbled on this link again! Here it is! So now we can continue the discussion. Could someone help me interpret these numbers, and please no "read this book if you want to know". Has somebody read the book and can help me out here?
http://www.tomshardware.com/news/z196-mainframe-microprocessor,11168.html
"Additionally, a 4-node system uses 19.5MB of SRAM for L1 private cache, 144MB for L2 private cache, 576MB of eDRAM for L3 cache, and 768MB of eDRAM for a level-4 cache."

I interpret this "4-node system" as a Mainframe with four sockets. Hence it has
19.5 + 144 + 576 + 768 = 1504.5MB cache in total. That is, 376MB of cache per socket. It all revolves around what is a "4-node system"? If it is a 4-socket system, then I think most people agree that closer to half a GB of cache per socket is hilarious. But if it is not 4-sockets, I am willing to reevaluate my standpoint. No problem.
Click to expand...
 
brutalizer said:
You are dead wrong on this. Smaller is better. Talk to any mathematician, you dont have to take my word for it.
Click to expand...
I won't take your word for it. I am friends with several post-docs in the field of mathematics and they don't believe smaller is always better.
 
jimmyb said:
I won't take your word for it. I am friends with several post-docs in the field of mathematics and they don't believe smaller is always better.
Click to expand...
I dont believe you. Ask them again. Beauty is everything. To create a short proof takes much effort and great understanding of the subject, all matemathicians agree on this. If not, they are not a mathematician.

If you ask someone something and they ramble for minutes without really giving you an answer - is that good? Someone who understands the subject is able to answer with 1-2 sentences. "If you can not explain it to a child, you dont understand the subject" as a Noble prize winner in physics said. Short is beautiful.
 
brutalizer said:
As I said, unnecessary transistors make the circuit more complex, it uses more power, chances for bugs are higher, more resources are used (smaller cpus have higher yield on the wafers), etc - the reasons are numerous to try to reduce the nr of transistors.
Click to expand...
Everything you've said here are generalizations that aren't always true:
  • Sometimes more transistors use less power
  • Sometimes more transistors means less bugs
  • Sometimes more transistors means higher yield
  • Sometimes more transistors means smaller area
You've done nothing to defend your specific claims about mainframe and x86 CPUs, do you have any evidence to support those claims?

brutalizer said:
There are several software systems that try to reduce the nr of transistors on the market - why if no one cares about bloat?
Click to expand...
I never said no one cares. Please don't put arguments in my mouth.
 
brutalizer said:
I interpret this "4-node system" as a Mainframe with four sockets. Hence it has
19.5 + 144 + 576 + 768 = 1504.5MB cache in total. That is, 376MB of cache per socket. It all revolves around what is a "4-node system"? If it is a 4-socket system, then I think most people agree that closer to half a GB of cache per socket is hilarious. But if it is not 4-sockets, I am willing to reevaluate my standpoint. No problem.
Click to expand...

The original PC Magazine article shows that your guess is wrong, as do the docs on the IBM website.

brutalizer said:
I agree with the last paragraph, in commercial software development the developers might not have time to refactor the code.
Click to expand...
I've exerted a lot of effort for very little progress.
 
I have to agree with brutalizer about the beauty of math (minimalist principles) and small, efficient code.
After talking to the senior DBA I work with, with over 30 years of experience in the field, I definitely can say that real coders worth their salt want as little programming/code as possible to get the job done.

He's written programs using everything from C to Java and Pearl, on every platform from the Zilog Z80 to modern mainframes.
Certain programming languages he prefers since he is able to get the same job done with less code, more efficiently.

More is not always better, I've learned that just from what little I do with programming and coding.


mikeblas said:
I've exerted a lot of effort for very little progress.
Click to expand...
Well, then I guess you will have to follow your own principles and do more! :D

hA44BD371
 
Red Falcon said:
I have to agree with brutalizer about the beauty of math (minimalist principles) and small, efficient code.
Click to expand...

If code size was the only metric that developers cared to optimize then they would likely all be using assembly or writing directly in machine code. brutalizer is making some very broad generalizations, seemingly unaware that they are sometimes not true.
 
jimmyb said:
If code size was the only metric that developers cared to optimize then they would likely all be using assembly or writing directly in machine code. brutalizer is making some very broad generalizations, seemingly unaware that they are sometimes not true.
Click to expand...
It all depends on how efficient you want the code to be (developer productivity is another measure of efficiency) and how much you trust the compiler. Lambdas for example can be used to write very elegant code, at the same time overusing them can be a headache.
There is no one size fits all, it all depends on the application. Often messy code can be a sign that the solution (although it may work) is poorly implemented).

KISS - Keep it Simple Stupid.
 
Red Falcon said:
After talking to the senior DBA I work with, with over 30 years of experience in the field, I definitely can say that real coders worth their salt want as little programming/code as possible to get the job done.
Click to expand...
Ideally, sure. Practically, it's just not possible to pursue the kind of endless minimization and aesthetic that brutalizer is insisting is ubiquitous and constant. Nobody's said "more is always better", but someone has said, repeatedly, that "less is always better and always pursued". And that's simply not true.

A developer who writes feature A wants to ship it; he doesn't want to re-write it again and again to make it optimal. He'll try to come up with a good implementation, and that's that. Time marches on, so he'll start working on feature B. Re-writing feature A to be smaller means he has no meaningful productivity, and has a non-zero chance of regressing the feature. Moving on to feature B means that he's got an opportunity to add value to the product and company and produce something that customers want.

"As simple as possible" means that a developer would chose a simpler, slower algorithm because it's simpler. In reality, the more complicated algorithm is preferred because performance is necessary. "As simple as possible" means a developer would chose to provide few features, no security, no user interface, and so on -- but instead these features are fundamental and required, and the resulting complexity is accepted and managed.
 
Last edited:
Wiseguy2001 said:
It all depends on how efficient you want the code to be...
Click to expand...
There are a whole range of considerations when developing software or hardware. Characterizations that insist a particular metric is *always* optimized as much as possible are untrue.
 
mikeblas said:
The original PC Magazine article shows that your guess is wrong, as do the docs on the IBM website.
Click to expand...
What? Can you explain more on this? I quote your link:
"...In a 4-node system, 19.5 Mbytes of SRAM are used for L1 private cache, 144 MB for L2 private cache, 576 MB of eDRAM for L3 cache, and a whopping 768 MB of eDRAM for a level-4 cache..."

This is exactly what I linked too, earlier. If you say I am wrong, could you please paste text proving I am wrong?
 
jimmyb said:
I asked them again. They confirmed that sometimes a larger mathematical proof can be better.

I guess this is the no-true mathematician argument?
Click to expand...
No, they are not mathematicians. That is for sure. You sound like this guy Mikeblas who claims he programmed lots - which he hasnt. No, your friends are not mathematicians.

If your friends have ever studied higher math, they should have known that mathematicians goes to great length to get rid of any superfluous and unnecessary statements. Great length. They should for instance, have heard about all the efforts to get rid of the parallell postulate:
http://en.wikipedia.org/wiki/Parallel_postulate#History
"...For two thousand years, many attempts were made to prove the parallel postulate using Euclid's first four postulates. The main reason that such a proof was so highly sought after was that, unlike the first four postulates, the parallel postulate isn't self-evident. If the order the postulates were listed in the Elements is significant, it indicates that Euclid included this postulate only when he realised he could not prove it or proceed without it.[7] Many attempts were made to prove the fifth postulate from the other four, many of them being accepted as proofs for long periods of time until the mistake was found..."

Many great mathematicians have wrestled with this, even the great Gauss - the greatest mathematician ever lived. If you can shorten a proof by cutting out unnecessary cruft - you do that. That is good research and worth publishing in a research paper. The reason is that to shorten a proof requires a lot of effort to gain a deeper understanding of some concepts. And very well worth pursuing.

There are MANY examples where mathematicians wrestle with cutting out unnecessary information, the parallell postulate only one example. If for instance, you could remove a statement in Peanos axiom system - that would be great news to the math community and would cause instantenous fame.

That you claim you have some math friends that are not familiar with this - that is just too weird. It is like you say "I have some pro gamers that play FPS games, and they just confirmed that high FPS is bull sh-t, some of the pros wins contests with 10fps or so". Now THAT would be silly, right? You are saying something similar silly now. Do you think ANY pro gamer in the FPS industry would say that? If they do - they are not pro gamers. You just know.
 
Last edited:
jimmyb said:
If code size was the only metric that developers cared to optimize then they would likely all be using assembly or writing directly in machine code. brutalizer is making some very broad generalizations, seemingly unaware that they are sometimes not true.
Click to expand...
Maybe I am not clear enough. When I talk about LoC - I am talking about the source code. Reducing the amount of code a developer needs to write, that is. If you are writing in assembler, then you need to write much much more code than usual. Or maybe, I am clear, maybe you did not know this? Maybe you did not know that assembler programmers uses up to... 10x more LoC?

jimmyb said:
Everything you've said here are generalizations that aren't always true:
  • Sometimes more transistors use less power
  • Sometimes more transistors means less bugs
  • Sometimes more transistors means higher yield
  • Sometimes more transistors means smaller area
You've done nothing to defend your specific claims about mainframe and x86 CPUs, do you have any evidence to support those claims?
Click to expand...
Hmmm... Do you know what I am talking about? Or do you know what you are talking about?




mikeblas said:
"As simple as possible" means that a developer would chose a simpler, slower algorithm because it's simpler. In reality, the more complicated algorithm is preferred because performance is necessary. "As simple as possible" means a developer would chose to provide few features, no security, no user interface, and so on -- but instead these features are fundamental and required, and the resulting complexity is accepted and managed.
Click to expand...
I did one of my Masters in algorithm theory and discrete math, for one of the best researchers in the world (if not the best, he has won several of the most famous discrete math and algo theory prices in the world).

I said earlier, if you can choose among two solutions that are sufficiently good (it could mean fast enough, both are equally fast) then you should choose the simpler solution. Simplicity is difficult to achieve and shows a deeper understanding - unless we are talking about trivial stuff which (we are not).


Wiseguy2001 said:
It all depends on how efficient you want the code to be (developer productivity is another measure of efficiency) and how much you trust the compiler. Lambdas for example can be used to write very elegant code, at the same time overusing them can be a headache.
There is no one size fits all, it all depends on the application. Often messy code can be a sign that the solution (although it may work) is poorly implemented).

KISS - Keep it Simple Stupid.
Click to expand...
This.

Messy code is often bloated and lot of unnecessary lines, and to condense the code and rip out everything unnecessary takes lot of effort. If you can condense 100 LoC down to 20 with no penalty in functionality/performance/etc, then you have done great! Especially as you aim for that the code is clear and readable. Just like what the LibreSSL guys are doing now with OpenSSL - they are ripping out all unnecessary code to make it less buggy and less bloated. And at the same time, the attack vector for malicious hackers decrease. Any programmer worth their salt takes pride in writing small and elegant code (provided it is sufficiently good). The LibreSSL devs talk about how much code they have deleted here, they mock the OpenSSL devs for having lot of unnecessary code, that they delete (implying that devs writing bloated code sucks and good devs writes minimalistic code)
http://opensslrampage.org/
http://arstechnica.com/information-...eyond-repair-claims-creator-of-libressl-fork/
"Theo De Raadt told ZDNet that his team has removed 90,000 lines of C code. "Even after all those changes, the codebase is still API compatible," he said. "Our entire ports tree (8,700 applications) continue to compile and work after all these changes."

mikeblas said:
Really, it isn't. No developer will spend a few days deleting code
Click to expand...
Que?
 
Last edited:
brutalizer said:
This is exactly what I linked too, earlier. If you say I am wrong, could you please paste text proving I am wrong?
Click to expand...
The numbers you've got are for the whole system. There are more than four sockets in the system; "4 nodes" means four nodes, not four sockets. You can prove yourself wrong, if you gave a damn about being correct.
 
brutalizer said:
...
Click to expand...

I honestly don't believe you understand what I am saying. I'm not going to restate what's already been said so I can only suggest that you re-read my posts carefully and try to understand specifically the claims that I am making and those that I am not.
 
mikeblas said:
The numbers you've got are for the whole system. There are more than four sockets in the system; "4 nodes" means four nodes, not four sockets. You can prove yourself wrong, if you gave a damn about being correct.
Click to expand...
I earlier asked for correction. If I am wrong, I am willing to change my mind, and I will stop say this again (that this Mainframe cpu has enormous amounts of cpu cache).

Question: So, what is a "node"? You claim that a node is not a socket, so how do you know that? Can you copy and paste text from a link that explains what a node is? How many sockets does 4 nodes correspond to?

I dont get it, but somehow ALL of the IBM supporters have great difficulties to copy and paste text to links. I have asked many different IBM supporters for explanations and EVERYBODY says "read this book on 1000 pages, but you are wrong, and I wont post text that proves you are wrong, just believe me, you are wrong". No one has ever pasted text. No one. Why is that IBMers have great difficulties with this? You are not the last IBMer that will not post text, believe me.
 
jimmyb said:
I honestly don't believe you understand what I am saying. I'm not going to restate what's already been said so I can only suggest that you re-read my posts carefully and try to understand specifically the claims that I am making and those that I am not.
Click to expand...
I have found something for you. Ask your so called "post-doc" friends in mathematics to watch this beginning probability class as MIT. Already in the very first lecture the professor discusses if another axiom is unnecessary or not. He says at 29:30
https://www.youtube.com/watch?v=j9WZyLZCBzs
"Mathematicians are pretty laconic, you dont say something if you dont have to say it."

And he therefore argues that these 3 axioms are the bare minimum and you dont need to add another axiom which would be unnecessary because you could derive it from the first three axioms. Let me repeat, Mathematicians dont like redundant information and go to great lengths to cut that out. I am surprised that your friends that are post-doc researchers in math dont know this. Normally, at all levels in math the mathematicians try to cut out unnecessary information. The only one who don't, are your so called math friends. I doubt they exist. Either that, or you do have some friends, but they dont know anything about higher math. In any case, you are WRONG. You did a mistake talking about math with someone knowledgeable. In math there is an right or wrong answer, so it is possible to see through your claims. You can make up claims in all other subjects that are hard to see through, but you can not make up claims in math.
 
You seem to be under the impression that I am arguing in favour of redundant axioms. I am not. Please re-read my posts and understand the scope of my claims.
 
so much ego here. let me simplify this for all of yall in an analogy: most women don't really care about size.

i don't think anyone here will argue that size doesn't matter, but some people here are arguing that it's simply not true that in ALL cases ALL sizes matter.
 
IBM should just create an cloud with all of these. Then the cost to entry to use their stuff won't be millions.
 
gigatexal said:
IBM should just create an cloud with all of these. Then the cost to entry to use their stuff won't be millions.
Click to expand...

They already do this, and the licensing is still $$$$.
Also, some of us like to phsycially work with the hardware; it isn't very [H] working with the "cloud".
 
Lol they're business model is stupid then. Still an awesome chip tho
 
gigatexal said:
Lol they're business model is stupid then. Still an awesome chip tho
Click to expand...

They have disolved/sold everything except for the POWER/PowerPC ISA and their patents and software licenses.
I wouldn't call it a stupid model, as everything they have done has been in favor of them, aka, their primary shareholders and board of directors; but yes, stupid for everyone else. :p

IBM is like Oracle, 10% technology and 90% lawyers.
 
I hope open power takes off and we get some boards to play with.
 
People who use MySQL have already given up on performance.
 
Status
Not open for further replies.
Back
Top