This will only work if you assume that cross core communication will be for free. As can be seen by the fact that opteron multi procs already use NUMA, this is not the case at least for memory access. Btw. it also is not true for non NUMA architectures, because there is the aspect of cache thrashing and cache synchronization. Additionally, setting up parallelism inside the function normally includes overhead as well, as you have to look at the inputs and bundle a package for each worker thread. Parallelizing on a low level means the application developer cannot put his knowledge about the characteristics of that special application into use to avoid that overhead.
One of the reasons might be that this is just an answer to SUN's whitewashing of their inability to deliver a competitive Sparc CPU by hyping their Niagara multi-core thingy. If you read the related slashdot threads, you see many people selling Niagara as the move with which SUN will regain domination in hardware - just by putting 16 underpowered core on one die. Hopefully with AMD showing (in the future) that they can also do this, but by utilizing competitive cores, it will be clear to anybody that SUN's stuff is just a marketing fluff.
Multi Proc Opterons are NUMA. And it don't need to be "seperate" banks of RAM in the way that Proc1 cannot talk to MemoryBank2, it's just that it has a bigger latency (or maybe even throughput, though I think this is very rare).
I follow you mainly. But for a depressing number of things where COTS software is used, there _is_ a better alternative in OSS. Better at least if you take cost into account. Oracle for instance has a fair advantage vs. Postgresql in high end DBs, the reality is that for many, many occasions, postgresql is enough and may even have less quirks. Says someone who has been going through the traumatic experience of migrating a medium complicated combination of apps from 8 to 9i. Or take the plethora of COTS content mgmt. systems, or app servers, in most cases there is someOSS which is not only cheaper, but also better and fits the problem more. The problem is that "downloading something free from the internet" implicitly poses a risk to whoever makes that decision.
Yes, you are right. It's not correct to say that the bugs "never surface", they are just a lot harder to trigger. And even if you create a system state like the one you described, it's still a lot easier to expose these kinds of bugs when testing on MP.
The point I was trying to make is that if one really wants to generalize like the OP did, then assume that multithreaded programs are more fragile, not more robust, especially on SMP machines.
What a lot of people don't realize is that threading per se doesn't at all guarantee faster performance on SMP systems.
When your threads running on different CPUs are working on a shared dataset that causes numerous issues concerning locking, cache alignment, cache coherency etc., you can get severe perfomance drops (in fact, you can get negative scalability). In fact, if you read in comp.programming.threads, you'll find many posts about people finding out that it's much easier to write good performing multi-processed applications with communicating over ipc that multi threaded applications.
Bull. The vast majority of really bad locking issues with multithreading never surface with singe CPU systems. Only when run on multiple cores these problems really come up. This is because only with several cores working on the same data your system has to rely on the correct thread programming to assure cache coherency.
You miss the point. Applying BMI on an individual and taking into account various other aspects is ok - no Doctor would ignore that he's just looking at one of your "UNUSUAL CASES" and tell e.g. Arnie to make a diet. But using BMI for a statistical analysis and drawing conclusions like done in the article is just silly - because it is just not the right differentiator for population groups, exactly because of the examples you and I gave.
The fundamental Problem is that they are taking the Body Mass Index as a measure for overweight. This is ridicoulous and will seriously skew the results to "slightly overweight" people - because more athletic people doing sports which are not only aerobic/endurance dominated tend to get a relativly high BMI. Example: Shaquille O'Neal height: 2,17m weight: 147,4 kg => BMI: 31.3
Yes, I chose different specs, because they are CPU benchmarks, and we were talking about CPUs - reread the first post you replied to. And yes, UltraSPARC IVs have been out for a while. But that just proves my point. It's all Sun has to offer at present (besides Opterons) - they are not able to withstand AMD, IBM and Intel in the area of high performance CPU Core technology. Even if Niagara is a full success, it will be countered by similiar CPU designs from these, just that each core is more than 2 times as fast as each Niagara core. Heck, I bet at least one of them has the designs already in their drawer.
Dude, I'm not comparing a single Proc PIV against these things. Part of my job is to decide which hardware will be bought for mid sized mission critical application servers (like the V40z and the V490/890). And Sun Sparcs at the moment simply do _not_ offer a good price/performance ratio, simply because this CPU is so damn slow, at it has been that way for a while. Please pay Spec or TPC a visit to inform yourself about this stuff.
IMO Sun is (also) playing the marketing game with its Niagara thingy. They didn't start to sell Opterons just because they liked to, they did because they can't compete. I expect Niagara to be competitive in certain task, and better than the competition in very specialiced task, the jury is just out to decide if these specialiced tasks do matter in reality. And despite what Sun wants me to believe, I don't expect Niagara to magically show superior results on Java Appservers in general.
The ironic thing is though that the Sparc IV gets destroyed by the single core AMD and Intel offerings, not to mention the IBM POWER (dual core) CPUs. For Sun, going dual core was just limitation of damage.
cPython itself (the standard python) has all the performance sensitive stuff written in C, also Zope, asyncore for asynchronous socket handling (now part of python) is written in C, python is used as a scripting language in a lot of commercial game engines, there's wypython, a wrapper for wxWidget (written in C++), there's Boost.Python, ctypes for working with native c-types in python, numpy, scipy etc. etc. See http://www.enthought.com/downloads/downloads.htm#d ownload for a python distribution containing a lot of stuff performance intensive stuff where core parts are coded in C.
Slashdot Mirror
Or
http://www.googlesightseeing.com/
And far too slow to compete with anything AMD says they could crank out in the future.
This will only work if you assume that cross core communication will be for free. As can be seen by the fact that opteron multi procs already use NUMA, this is not the case at least for memory access. Btw. it also is not true for non NUMA architectures, because there is the aspect of cache thrashing and cache synchronization.
Additionally, setting up parallelism inside the function normally includes overhead as well, as you have to look at the inputs and bundle a package for each worker thread.
Parallelizing on a low level means the application developer cannot put his knowledge about the characteristics of that special application into use to avoid that overhead.
One of the reasons might be that this is just an answer to SUN's whitewashing of their inability to deliver a competitive Sparc CPU by hyping their Niagara multi-core thingy.
If you read the related slashdot threads, you see many people selling Niagara as the move with which SUN will regain domination in hardware - just by putting 16 underpowered core on one die.
Hopefully with AMD showing (in the future) that they can also do this, but by utilizing competitive cores, it will be clear to anybody that SUN's stuff is just a marketing fluff.
Multi Proc Opterons are NUMA. And it don't need to be "seperate" banks of RAM in the way that Proc1 cannot talk to MemoryBank2, it's just that it has a bigger latency (or maybe even throughput, though I think this is very rare).
Well, besides the travel-by-plane thingy, look at victorinox knifes:
http://www.thinkgeek.com/gadgets/tools/3653/
http://www.victorinox.com/newsite/en/index.htm
This phenomenon (unrelated posts) seems to be quite frequent in this article. Maybe something wrong with /.?
I follow you mainly. But for a depressing number of things where COTS software is used, there _is_ a better alternative in OSS. Better at least if you take cost into account. Oracle for instance has a fair advantage vs. Postgresql in high end DBs, the reality is that for many, many occasions, postgresql is enough and may even have less quirks. Says someone who has been going through the traumatic experience of migrating a medium complicated combination of apps from 8 to 9i.
Or take the plethora of COTS content mgmt. systems, or app servers, in most cases there is someOSS which is not only cheaper, but also better and fits the problem more.
The problem is that "downloading something free from the internet" implicitly poses a risk to whoever makes that decision.
It sounds like a more limited (this is not meant as a criticism) version of acquisition used in Zope. Well obviously zope does have the lockin effect.
I don't know if you know it, maybe you get some ideas.
Yes, you are right. It's not correct to say that the bugs "never surface", they are just a lot harder to trigger. And even if you create a system state like the one you described, it's still a lot easier to expose these kinds of bugs when testing on MP.
The point I was trying to make is that if one really wants to generalize like the OP did, then assume that multithreaded programs are more fragile, not more robust, especially on SMP machines.
What a lot of people don't realize is that threading per se doesn't at all guarantee faster performance on SMP systems.
When your threads running on different CPUs are working on a shared dataset that causes numerous issues concerning locking, cache alignment, cache coherency etc., you can get severe perfomance drops (in fact, you can get negative scalability). In fact, if you read in comp.programming.threads, you'll find many posts about people finding out that it's much easier to write good performing multi-processed applications with communicating over ipc that multi threaded applications.
Bull. The vast majority of really bad locking issues with multithreading never surface with singe CPU systems. Only when run on multiple cores these problems really come up. This is because only with several cores working on the same data your system has to rely on the correct thread programming to assure cache coherency.
And
""computers are state machines. Threads are for people who can't program state machines""
Alan Cox
You miss the point. Applying BMI on an individual and taking into account various other aspects is ok - no Doctor would ignore that he's just looking at one of your "UNUSUAL CASES" and tell e.g. Arnie to make a diet.
But using BMI for a statistical analysis and drawing conclusions like done in the article is just silly - because it is just not the right differentiator for population groups, exactly because of the examples you and I gave.
Yeah. As I posted above, Shaquille O'Neal has a BMI of over 31 - and I think his cardiovascular system is quite ok.
The fundamental Problem is that they are taking the Body Mass Index as a measure for overweight. This is ridicoulous and will seriously skew the results to "slightly overweight" people - because more athletic people doing sports which are not only aerobic/endurance dominated tend to get a relativly high BMI.
Example:
Shaquille O'Neal
height: 2,17m
weight: 147,4 kg
=> BMI: 31.3
Yeah, that sounds like using BMI is a good idea.
Yes, I chose different specs, because they are CPU benchmarks, and we were talking about CPUs - reread the first post you replied to. And yes, UltraSPARC IVs have been out for a while. But that just proves my point. It's all Sun has to offer at present (besides Opterons) - they are not able to withstand AMD, IBM and Intel in the area of high performance CPU Core technology. Even if Niagara is a full success, it will be countered by similiar CPU designs from these, just that each core is more than 2 times as fast as each Niagara core. Heck, I bet at least one of them has the designs already in their drawer.
We were talking about CPUs, not the overall systems, let's see what SPEC tells us:
CINT 2000 (single CPU, single Core):
Best overall: AMD: 1854
[...]
Best UltraSPARC IIIi: 845 (submitted Jan-2005!)
CFP2000 (single CPU, single Core):
Best overall: IBM POWER5 (SMT off): 2796
[...]
Best UltraSPARC IIIi: 1353 (submitted Jan-2005!)
nough said
Dude, I'm not comparing a single Proc PIV against these things. Part of my job is to decide which hardware will be bought for mid sized mission critical application servers (like the V40z and the V490/890).
And Sun Sparcs at the moment simply do _not_ offer a good price/performance ratio, simply because this CPU is so damn slow, at it has been that way for a while. Please pay Spec or TPC a visit to inform yourself about this stuff.
IMO Sun is (also) playing the marketing game with its Niagara thingy. They didn't start to sell Opterons just because they liked to, they did because they can't compete.
I expect Niagara to be competitive in certain task, and better than the competition in very specialiced task, the jury is just out to decide if these specialiced tasks do matter in reality. And despite what Sun wants me to believe, I don't expect Niagara to magically show superior results on Java Appservers in general.
The ironic thing is though that the Sparc IV gets destroyed by the single core AMD and Intel offerings, not to mention the IBM POWER (dual core) CPUs. For Sun, going dual core was just limitation of damage.
Do you need to backspace/space mutliple times each time you switch to a new block level?
No, most of the editors (not also python enabled ones) don't work that way:
indenting: press TAB
dedenting: press backspace
on save: convert the TAB to spaces.
Editors with python syntax support (like emacs,vim, etc. etc.) autoindent if you type something like:
def methodname(): and hit enter.
I'm not sure, but have you looked at APE for the object persistence?
Those 4,000 users now save 3 seconds, 10 times an hour, 8 hours a day. It's like getting an extra 33 employees for free.
Did a consultant compute that number?
Huh?
d ownload for a python distribution containing a lot of stuff performance intensive stuff where core parts are coded in C.
cPython itself (the standard python) has all the performance sensitive stuff written in C, also Zope, asyncore for asynchronous socket handling (now part of python) is written in C, python is used as a scripting language in a lot of commercial game engines, there's wypython, a wrapper for wxWidget (written in C++), there's Boost.Python, ctypes for working with native c-types in python, numpy, scipy etc. etc.
See http://www.enthought.com/downloads/downloads.htm#