Re:Does linux support hypertrheading?
on
Linux SMP Round-Up
·
· Score: 1
You are correct. There is no connection between the cache and HT. This is why my comment says that "half the cache (or so) will be used for each thread." There is no formal relationship between the fact that the CPU is HT'ed into "2" CPU's and the cache: hence, the "or so" part.
If one CPU is in a nice, tight loop and the other is not in a loop at all, the majority of the cache will be used for the non-looping CPU. Because the looping CPU is not fetching more and different instructions, there's nothing to cache. However, in the real world, with two unrelated threads, something approaching half of the instructions in the cache will belong to each thread. Not by design, but by circumstance.
I cringe every time I hear something like this being compared with Domino. Yes, Domino does e-mail. Yes, Domino does calendaring. But Domino is so much, much more.
Anyone who has ever used Domino's document management tools or developed an application for Notes knows exactly what I mean. You have the ability to develop highly advanced applications, not just folders full of sticky notes (e.g. Exchange). You don't have filing cabinets full of sticky notes, do you? Why should your database?
The biggest disadvantage of Domino is the fact that developing for it is kind of its own little world. I'm looking forward to Domino R7's integration with WebSphere. But even until then, Domino gives you a document management development environment second to none.
The weird thing is that the feature that everyone looks at Domino most closely for, e-mail, is its weakest point. That's what comes from building e-mail around a document-mangement platform, instead of building document management around an e-mail platform.
Re:Does linux support hypertrheading?
on
Linux SMP Round-Up
·
· Score: 1
In fact, a lot of work recently has gone into NUMA support (links here and here). HT can be seen as a form of NUMA. Because of the effects of a CPU's cache, some processors are better suited than others for handling a particular thread. Like you mentioned, moving between logical processors on the same physical processor is much better than moving between physical processors. So, the scheduler must have some clues as to the nature of the CPU's it's working with.
As you can see, not only does Linux support HT out of the box (as any SMP-aware OS would, really), it's also working to handle HT in the most effective way possible.
Re:Does linux support hypertrheading?
on
Linux SMP Round-Up
·
· Score: 1
You would be wrong. The grandparent poster had it exactly correct.
The number of pipelines in a HT CPU is exactly the same as a non-HT processor. The instruction decode, prefetch, etc. is modified, but the bulk of the pipeline is the same. This is merely a way to extract extra parallelism from the code with hardware. By having two completely separate threads of program execution running in "parallel", you cut down on interdependencies between them to near zero. This is, of course, assuming a fully reentrant OS (otherwise OS calls could block on each other), but in practice this works pretty well.
The fact that you get 30% improvement for effectively the exact same silicon shows how important keeping the pipeline full is. Because of the huge length of the P4 pipeline (and the huge penalty for stalls, mispredicted branches, etc.), you must have a very large number of unrelated instructions. Normally, this is hard to come by in x86 code. HT goes a long way to keeping the pipelile full.
The downside of HT is its effect on the cache. Because you have two unrelated threads running on the same CPU, half the cache (or so) will be used for each thread. In effect, this halves the size of the cache for each thread. This isn't the end of the world, but it will require larger caches as time goes on. Of course, that's typical, anyway.
The interesting thing will be to see how far HT will allow Intel to go. With a larger pool of unrelated instructions, can Intel double the length of the pipeline without reducing pipeline stalls beyond a non-HT processor? I doubt they could push it quite that far, but there is no doubt it will allow them to lengthen the pipeline even farther while still maintaining overall better performance than a non-HT processor.
As an aside, I think this also shows the brilliance of Intel. Every time you think that CISC has run out of gas, Intel figures out a way around it. First, the silicon to handle all those (variable length) instructions was getting nuts. No problem: uOps. Then, even with a fairly magical branch predictor, parallelism was getting hard to come by. No problem: HT. Every time, a powerful solution.
Of course, by keeping the pipeline down, AMD seems to do just *fine* without HT, but I digress...:)
The important part about being a consultant is meeting the business needs of a business. Are RAID servers good? Yes. Do I always put them in? No. If it's a small office and it's the difference between a real fileserver and a crappy clone in the corner running Windows 98, I lose the RAID.
It's not the right technical decision. But it is the right business decision. The right business decision is always the right decision. It's the one that balances the technical, financial, political, etc. decisions into the one that best fits the organization both today and into tomorrow.
The only problem with this is that cable losses at 2.4GHz is enormous. Even with decent quality cable (LMR400) you're looking at 2db for every 10 meters. When you're talking 500mW, that's not a lot to lose...
The problems is, this wasn't a counter-point article. It is a legal brief. Admittedly, it has not been filed: it is a draft. However, as a draft of a legal brief, praying for the end of one of the litigants isn't considered a strong legal argument...
The example quoted by one of the other replies was an even better example. I think that the brief would be much more effective for legal-types if it didn't break down into discussions of the blessed OpenSource custodians of our fragile Internet freedoms.
I'm not saying that ESR's points are not valid. I don't feel *nearly* as strongly as he does, but his concerns are valid. However, such statements make the brief begin to read like a manifesto, not a reasoned legal argument.
This was particularly disappointing because the first 70% of the brief was so dead-on!
I just finished reading the brief. I must say that for the first half or so, I was very impressed with it. It was simple, logical and factual. However, by the end, it seemed to devolve into a statement of beliefs and feelings that, to me, did not feel right in a court brief. For example:
SCO's complaint, in all its brazen mendacity, is the last gasp of proprietary Unix. The open-source community and its allies are more than competent to carry forward the Unix tradition. We pray that all assertions of exclusive corporate ownership over this tradition be given a swift and merciful end.
Am I the only one who thought that this was not the forum for such OpenSource flag-waving?
This is for the 667MHz chip (which I believe uses the same core). Short answer: a C3 is about 1/3 slower than a Duron or Celeron of similar speed in business benchmarks.
I use the 533MHz Eden processor in a number of embedded-type projects, where CPU power is not overly important. No moving parts, though, is, and the 533MHz doesn't need a CPU fan!
I'm not sure that the odds of PowerBall are only 120 Million to 1: that sounds **WAY** too low. But even if that is correct, then yes, if the jackpot is more than $120 Million, you will make money if you buy every possible lottery ticket.
There are two things that go with this. 1) If someone *else* hits the jackpot and you have to split it, you lose money. So, it's not guaranteed to make money. 2) The lottery people don't care who wins, or how much. They get 50% of the income no matter what. So if you spend $120 Million to win a, say, $200 Million jackpot, so what? They still made $60 Million off of you, and next week they have a $60 Million jackpot!
In fact, this has been done: an investment company bought all 42 Million tickets in a lottery worth quite a bit more than that (something like $100 Million?). They were lucky: nobody else hit the jackpot. They had problems, though: several thousand numbers were left uncovered when a lottery ticket machine broke down and they couldn't get more tickets in time.
Interesting. I just checked Google. According to this, you're right: the odds are slightly higher than one in 120 Million...
You've obviously never heard electrostatic speakers.
Imagine a panel of thin metal 2 feet wide by 5 feet tall with perforated with thousands of holes maybe half an inch in diameter. Actually, it's two layers of metal with something like a clear mylar sheet between them. Changes in charge cause the mylar to vibrate, generating sound.
I said exactly what you said to the salesman: "How can they push enough air for bass?" He just smiled and turned them on...
Trust me: thousands of little speakers working in unison can generate a pressure wave plenty big. Of course, for speakers costing $10,000 a pair, I'd expect that!
Wow. It sure seemed that Mr. Perens was involved before, by the sheer volume of replies here. But it's even more than that: when the SlashCode prevented him from posting anymore, he sent me a personal e-mail!
A personal e-mail for someone making snide comments at his expense? I'm impressed... If he puts anywhere near as much effort into these books, I'm sure they will be a success.
Wow! I've never seen someone respond so much to a topic they were related to, and get so much karma because of it. Share the wealth, buddy!:)
Actually, it's nice to see someone so personally involved: with his own projects, the community in general, and with individuals. If the content of these books are competitive, they will definitely move to the front of my buying list.
This is been done for years now.
A couple of links. Check the dates.
http://www.3dimagery.com/pointer.html
http://www.holoworld.com/holo/diode.html
Tim Massey
Don't say I never gave you anything
Slashdot Mirror
If one CPU is in a nice, tight loop and the other is not in a loop at all, the majority of the cache will be used for the non-looping CPU. Because the looping CPU is not fetching more and different instructions, there's nothing to cache. However, in the real world, with two unrelated threads, something approaching half of the instructions in the cache will belong to each thread. Not by design, but by circumstance.
Anyone who has ever used Domino's document management tools or developed an application for Notes knows exactly what I mean. You have the ability to develop highly advanced applications, not just folders full of sticky notes (e.g. Exchange). You don't have filing cabinets full of sticky notes, do you? Why should your database?
The biggest disadvantage of Domino is the fact that developing for it is kind of its own little world. I'm looking forward to Domino R7's integration with WebSphere. But even until then, Domino gives you a document management development environment second to none.
The weird thing is that the feature that everyone looks at Domino most closely for, e-mail, is its weakest point. That's what comes from building e-mail around a document-mangement platform, instead of building document management around an e-mail platform.
As you can see, not only does Linux support HT out of the box (as any SMP-aware OS would, really), it's also working to handle HT in the most effective way possible.
The number of pipelines in a HT CPU is exactly the same as a non-HT processor. The instruction decode, prefetch, etc. is modified, but the bulk of the pipeline is the same. This is merely a way to extract extra parallelism from the code with hardware. By having two completely separate threads of program execution running in "parallel", you cut down on interdependencies between them to near zero. This is, of course, assuming a fully reentrant OS (otherwise OS calls could block on each other), but in practice this works pretty well.
The fact that you get 30% improvement for effectively the exact same silicon shows how important keeping the pipeline full is. Because of the huge length of the P4 pipeline (and the huge penalty for stalls, mispredicted branches, etc.), you must have a very large number of unrelated instructions. Normally, this is hard to come by in x86 code. HT goes a long way to keeping the pipelile full.
The downside of HT is its effect on the cache. Because you have two unrelated threads running on the same CPU, half the cache (or so) will be used for each thread. In effect, this halves the size of the cache for each thread. This isn't the end of the world, but it will require larger caches as time goes on. Of course, that's typical, anyway.
The interesting thing will be to see how far HT will allow Intel to go. With a larger pool of unrelated instructions, can Intel double the length of the pipeline without reducing pipeline stalls beyond a non-HT processor? I doubt they could push it quite that far, but there is no doubt it will allow them to lengthen the pipeline even farther while still maintaining overall better performance than a non-HT processor.
As an aside, I think this also shows the brilliance of Intel. Every time you think that CISC has run out of gas, Intel figures out a way around it. First, the silicon to handle all those (variable length) instructions was getting nuts. No problem: uOps. Then, even with a fairly magical branch predictor, parallelism was getting hard to come by. No problem: HT. Every time, a powerful solution.
Of course, by keeping the pipeline down, AMD seems to do just *fine* without HT, but I digress... :)
The important part about being a consultant is meeting the business needs of a business. Are RAID servers good? Yes. Do I always put them in? No. If it's a small office and it's the difference between a real fileserver and a crappy clone in the corner running Windows 98, I lose the RAID.
It's not the right technical decision. But it is the right business decision. The right business decision is always the right decision. It's the one that balances the technical, financial, political, etc. decisions into the one that best fits the organization both today and into tomorrow.
The only problem with this is that cable losses at 2.4GHz is enormous. Even with decent quality cable (LMR400) you're looking at 2db for every 10 meters. When you're talking 500mW, that's not a lot to lose...
The example quoted by one of the other replies was an even better example. I think that the brief would be much more effective for legal-types if it didn't break down into discussions of the blessed OpenSource custodians of our fragile Internet freedoms.
I'm not saying that ESR's points are not valid. I don't feel *nearly* as strongly as he does, but his concerns are valid. However, such statements make the brief begin to read like a manifesto, not a reasoned legal argument.
This was particularly disappointing because the first 70% of the brief was so dead-on!
I just finished reading the brief. I must say that for the first half or so, I was very impressed with it. It was simple, logical and factual. However, by the end, it seemed to devolve into a statement of beliefs and feelings that, to me, did not feel right in a court brief. For example:
SCO's complaint, in all its brazen mendacity, is the last gasp of proprietary Unix. The open-source community and its allies are more than competent to carry forward the Unix tradition. We pray that all assertions of exclusive corporate ownership over this tradition be given a swift and merciful end.
Am I the only one who thought that this was not the forum for such OpenSource flag-waving?
http://www.anandtech.com/showdoc.html?i=1396&p =6
This is for the 667MHz chip (which I believe uses the same core). Short answer: a C3 is about 1/3 slower than a Duron or Celeron of similar speed in business benchmarks.
I use the 533MHz Eden processor in a number of embedded-type projects, where CPU power is not overly important. No moving parts, though, is, and the 533MHz doesn't need a CPU fan!
I'm not sure that the odds of PowerBall are only 120 Million to 1: that sounds **WAY** too low. But even if that is correct, then yes, if the jackpot is more than $120 Million, you will make money if you buy every possible lottery ticket.
There are two things that go with this. 1) If someone *else* hits the jackpot and you have to split it, you lose money. So, it's not guaranteed to make money. 2) The lottery people don't care who wins, or how much. They get 50% of the income no matter what. So if you spend $120 Million to win a, say, $200 Million jackpot, so what? They still made $60 Million off of you, and next week they have a $60 Million jackpot!
In fact, this has been done: an investment company bought all 42 Million tickets in a lottery worth quite a bit more than that (something like $100 Million?). They were lucky: nobody else hit the jackpot. They had problems, though: several thousand numbers were left uncovered when a lottery ticket machine broke down and they couldn't get more tickets in time.
Interesting. I just checked Google. According to this, you're right: the odds are slightly higher than one in 120 Million...
Of course, thier banners have been stripped because of NCAA violations, so it's arguable how really fab they were, but I digress.
I agree. That is hilarious, not redundant. Though, the !1 is even better... If I had mod points, I'd give you both one.
Imagine a panel of thin metal 2 feet wide by 5 feet tall with perforated with thousands of holes maybe half an inch in diameter. Actually, it's two layers of metal with something like a clear mylar sheet between them. Changes in charge cause the mylar to vibrate, generating sound.
I said exactly what you said to the salesman: "How can they push enough air for bass?" He just smiled and turned them on...
Trust me: thousands of little speakers working in unison can generate a pressure wave plenty big. Of course, for speakers costing $10,000 a pair, I'd expect that!
A link for your review: Ultimate Electrostatic speakers. Notice the frequency response: 24Hz to ultrasonic...
A personal e-mail for someone making snide comments at his expense? I'm impressed... If he puts anywhere near as much effort into these books, I'm sure they will be a success.
And I just became Mr. Perens' friend.
Actually, it's nice to see someone so personally involved: with his own projects, the community in general, and with individuals. If the content of these books are competitive, they will definitely move to the front of my buying list.
Maybe they could put the Internet in the same lock box they put Social Security in? Doesn't get any safer than that!
And yes, there is a Linux version.
Tim Massey
This is been done for years now. A couple of links. Check the dates. http://www.3dimagery.com/pointer.html http://www.holoworld.com/holo/diode.html Tim Massey Don't say I never gave you anything