What is Digg?98 Comments
- Orangutan, on 10/12/2007, -5/+53i think it was last time i opened windows explorer
- maninblac1, on 10/12/2007, -3/+29*rolls eyes*
When will the general computing industry understand this. The more cores you add the more performance you get, however it's not directly proportional persay.
A single application will not run faster than it normally would on a single core system vs. on a dual core system, since if that application is single threaded, it can only take advantage of 1 CPU at a time. Dual core is a doubling a resources, applications simply do not take advantage of that doubling at this point.
HOWEVER, a critical factor is always missed by the opponents of this advancement, even if a program can only access half of the computer's reasources, this does not mean the other half is not used. While your program cranks away only using 40% of one of the CPU's the OS is free to schedual any other non-conflicting application to use the other CPU. Therefore, in the idealist world, throughput is bigger so overall performance goes up.
Obviously this isn't 100% true, but technically speaking, the more cores you have, the more performance/throughput period. - goat2, on 10/12/2007, -13/+28"What sucks on multiprocessing is Windows"
wow blatant ***** windows bashing and apple jackoffery.
windows manages multi core systems perfectly, you ***** idiot - Nodren, on 10/12/2007, -3/+17if a computer has two cores, typically the operating system can manage both cores with little problem, where having them really comes in handy, is a program not designed for multiple cores, will still only take up one core with its resources, so with a core duo or athlon x2 you could have itunes ripping a cd while browsing a site full of flash(both cpu intensive tasks) and you wouldnt notice a slowdown on either program. though the true power of dual core, and what the article mentions, is creating a program to use both cores, so instead of itunes using up 1 core completely and taking 5 minutes to rip a cd, it uses up both cores completely and takes 2 and a half minutes. but thats the part that takes alot of effort, dual core still works quite well otherwise.
- maninblac1, on 10/12/2007, -3/+16A clearer more relatable statement is that, pretend that windows or OSX schedules all of it's background tasks (and itself) to run on one of the 2 cores, now you have a single core all to yourself that you don't have to share with the OS.
If you think about this logically, your applications will run "faster" since they do not have to compete with the OS for CPU time.
This concept can be expanded into essentially an endless degree, until you have more cores than you have processes or threads. Right now i'm running 758 threads, imagine a core for every thread. (not necessary but you get the point) - LaughingMan11, on 10/12/2007, -2/+10Not everything needs to be massively parallelized in order to maximize performance. There are many cases where throwing extra threads at a workload will simply not improve performance, or will degrade performance because you take a hit with synchronization between threads.
In the same way, not all applications need to support 64-bit math or a 64-bit address space to run most efficiently.
It's too broad a generalization to say that all apps are antiquated and need to be multithreaded in the future to optimize for multi-core machines of today and tomorrow... most of the apps we use today don't need to be, and probably won't be optimized in the future unless there is a damn good reason. - kammodmatt, on 10/12/2007, -7/+14This digg underlines a huge problem today: we have these fast 64 bit multicore processors that are running 32 bit applications that are not optimized for parallel processing. Some times you need to adapt or die and I think that in order to keep up with the massive progress in hardware development, software developers are going to have to start removing backwards compatibility. Whens the last time you ran an application that was more than a year or two old anyways?
- maninblac1, on 10/12/2007, -8/+15@smpdigital
I'm going to say it, i shouldn't, but i'm going to say it, cause you had to mention the MAC/PC debate. You're an idiot
Multiprocessing power goes to OSX because it is UNIX based, UNIX is very good at multi-"processing", multi-threading goes to Windows because windows is very good at multi-threading. UNIX doesn't have the constructs to handle massively multi-threaded applications. The UNIX/Vista kernel engineer explains the key differences in the approaches in his interview with channel9.
And when we talk about the scientific world we're not talking 1 or 2 threads here, there may be thousands or more, how else can you manage to occupy a super computer with thousands of processors, i would suggest than that coding for a dual core or quad core environment is entirely different than scientific computing. - Berkana, on 10/12/2007, -1/+8This is yet another reason why I'm a huge advocate of functional programming. Optimal parallelism is trivial to achieve in functional programming. In FP, programs are naturally arranged in a tree. (Lisp for example; all the functions in Lisp are lists, and nested lists naturally form trees.) Trees naturally form Hasse Diagrams; their structure shows dependencies. Simply execute any functions that are not dependent on each other in parallel right off the code. No special optimizer necessary.
If there is not a mass migration toward functional programming, all the multi-core chips out there will be underutilized. The specialized optimization needed to make code take advantage of multi-core chips, even with automated tools, will take a long time and a lot of development to be able to achieve the parallelism FP affords right off the bat.
BTW, FP is how Google is able to do their searches so quickly; they implemented their map-reduce operation in terms of compositions of functions. - Rikkochet, on 10/12/2007, -8/+14I've got a dual core Athlon system. It is faster and doesn't suck. Thanks for the vote, though.
- JCaptainP, on 10/12/2007, -2/+8Berkeley has a good webcast concerning the crossroads between uniprocessors and multiprocessors http://webcast.berkeley.edu/courses/stream.php?type=real&webcastid=14773
Or you can view the whole course http://webcast.berkeley.edu/courses/archive.php?seriesid=1906978278 - Civil44, on 10/12/2007, -10/+15unless your using it for gaming or video editing your not going to notice a huge performance gain while say surfing the web. The duo's are not out of this world faster than the amd's. I have a 4400 amd at the house and I work on a 6800 duo at the job. I use them both for video editing and photo manipulation. The difference is negligible.
- LaughingMan11, on 10/12/2007, -1/+6Your example is flawed... or you just explained it wrong.
You're ripping 2 DVDs simultaneously on a dual core system? That means you've got 2 DVDs in 2 DVD-ROM drives on your PC on a dual core system, and it takes 30 minutes to complete the whole task?
Yet if you rip one DVD it takes 15 minutes? But you're on the same dual core system? This surprises you?
Ripping a DVD ( i assume you mean using DeCSS ) is not really a demanding CPU application anyway. It's more demanding on your IO.
If you had said *encoding* 2 DVD movies worth simultaneously, and not varied the number of movies, but the number of cores, you would have had a valid comparison.
Encoding 2 DVD movies to xvid or something would be much faster (approaching 100% faster) on a dual core system than encoding the same 2 movies on a single core system. - inactive, on 10/12/2007, -4/+8Thats a common misconception about HT.
It DIDN'T run 2 threads at the same time. It just was able to use the wasted CPU cycles caused by having a pipeline several stages too long (and the massive latency this caused if the branch prediction thing screwed up) to run another thread while the pipelines were being refilled.
Trust intel to use a major ***** as a selling point, and for stupid consumers to completely buy the lie! - maninblac1, on 10/12/2007, -3/+6Every computer scientist has to start with "Hello World!" so your statement is catagorically wrong.
:-) - LaughingMan11, on 10/12/2007, -3/+6Wrong. For the most part, writing threaded programs still require a lot of hand holding by the programmer, even in languages like C/C++. Current compilers aren't smart enough to optimize your badly written parallel code.
Some languages like Java and others have support for structures like Monitors that help make threaded programming easier, but that doesn't guarantee maximal performance.
Writing good, high performance threaded programs requires expertise. - inactive, on 10/12/2007, -1/+4The big problem is that people expect single applications to run at double the speed on dualcore. That wont happen.
What dualcore does, though, is allow you to run twice as many applications, and/or avoid those annoying stalls when a single core computer spens 100% of its processing power.
Stalls while multitasking annoyed the hell out of me, and was the reason I got my dual core - and I'm very happy indeed. I'd never go back to singlecore.
However, people running one single application at a time (and which do not do something which is suitable for splitting into threads), will not notice any improvement. Games is the most typical example of apps which hardly benefit from dualcore. - maninblac1, on 10/12/2007, -3/+5@vuke69
Yes, and as you know most have custom OS's, many derivants of Linux or Unix as shown in the chart, however i assure you quite firmly they aren't running Ubuntu or fedora. They may have the core systems, but other than that, it's homebrew, or scientific brew if i can go that far.
Windows isn't made for the scientific community, there is a difference between home PC multi-threading and scientific multi-threading. Quite a big difference, and in a world where every extra second and CPU cycle is $$$, they can't be wasted on random system services for the home user.
With linux especially you find you can trim the fat, it's open source so you can customize it to your hardware, but you're talking about two totally different animals, scientific computing has little to zero programming relation to PC applications. - inactive, on 10/12/2007, -1/+3Why you are being dug down is beyond me. I work almost exclusively on dual core dual cpu systems and programming is exactly the same as multithreaded apps. I've worked on MIPS cpu's with 32 cores too.
Linux will schedule the threads on different CPU's, if you know what you are doing.
You just need to worry where to schedule processes (or threads) if you need to worry about shared L2's if you are sharing data between multiple threads. - donatj, on 10/12/2007, -2/+4I find my 4200+ handles multitasking awesomely. Sometimes I'll set stuff to run on the individual cores so I can say encode a dvd on the one core while I continue doing other things on the other.
- pgup, on 10/12/2007, -3/+5I'm guessing you do not have one bit of programming knowledge at all?
- anagami, on 07/02/2008, -0/+2"Comparing an operating system written for the desktop and typical server tasks with supercomputers is pointless."
I disagree. Having a bullet-proof OS that is reliable in supercomputers and scales (Unix/POSIX) is a HUGE benefit for a PC (a reliable OS is a significant attribute regardless of use, if you still don't get it). - LaughingMan11, on 10/12/2007, -2/+4A lot of people said the same thing about the first dual core processors when they appeared a few years ago.
Bear in mind that there are a fairly big category of applications that are presently highly threaded and can take advantage of however many cores you've got. Media creation applications, especially video encoders, are very easily threaded, and speed up the more cores you throw at it.
Quad core won't be for everybody, but there will be people out there who will take advantage of it, especially in the creative industry. - anagami, on 07/02/2008, -0/+2""Two, yes exactly two of the top 500 use windows."
What does this have to do with the other 99.99999% of computers on the planet?"
That those computers have an OS that doesn't scale and is not reliable for 'real computing'. And it's less than 95% - vuke69, on 10/12/2007, -2/+4maninblac1:
You brought up massively multi-threaded & scientific applications, which is primarily the relm of supercomputers. So thats what I commented on. I was replying to your comments , not the story in general. - Almadiel, on 10/12/2007, -1/+3It isn't so much that parallel programming is difficult, as it is that programmers are generally resistant to change. Too many people still think that purely linear procedural programming is the way everything should be done. But hey, if you build it they will come, and people are starting to come around.
- LaughingMan11, on 10/12/2007, -2/+4AMD's processors aren't horrible. They are no longer top dog, but they are still respectable and a very decent architecture.
- archlich, on 10/12/2007, -2/+3there's still 16 bit prorgrams in windows xp =) granted they aren't critical
- EtherGnat, on 10/12/2007, -2/+3"Well as soon as HL2 (or any other desktop application) is written to be massively multi-threaded, you would have at least a sliver of an argument."
In the future if HL2 is massively multi-threaded and Windows can't handle it then YOU'LL have a sliver of an argument. In the meantime you made my point--applications average people use aren't massively multi-threaded and they aren't written for supercomputers. Windows isn't a smart choice for supercomputers. If you're running a supercomputer that's important. If you're running Quicken and iTunes on a PC it's irrelevant.
Consumer oriented software will evolve. Windows will evolve with it or die. Comparing an operating system written for the desktop and typical server tasks with supercomputers is pointless. - maninblac1, on 10/12/2007, -0/+1UNIX supports threads yes and I never said it didn't, but UNIX (as per the interview with the kernel engineer for NT stated in his channel9 interview about Vista), UNIX concentrates on multi-processing and less on multi-threading, his claim is that the NT kernel better manages multi-threads natively than UNIX, and i'm not speaking the ease of programming but the efficiency of the OS.
I took his statement naturally with a grain of salt, but i feel it is credible since he worked with UNIX for many years, before working on the NT kernel construction. - freebit50, on 10/12/2007, -4/+5Programming for multiple cores is not as difficult as everyone would like you to believe. Some of the great ideas exposed in function programming can be used with mainstream languages. This page: http://www.freebit50.com/blog/2006/09/200609.html goes into great detail how to implement the parallelism that functional programming allows using a mainstream language like C#. My current ideas regarding this have advanced quite a bit beyond what is on my blog while still remaining simple and easy to implement. My code ends up being very componentized and easily reusable. My biggest issue was the exception architecture needed to troubleshoot my code. However, that problem is solved. I don't run into races or deadlocks, ever, period. The level of parallelism is fine grained and approaches the maximum theoretical limit possible. My locking code ends up being limited to changing the overall state of an object from one state to another in one operation. This ensures that the object is never in an inconsistent state. It is also extremely fast. My locking ends up enclosing a group of assignment statements only. Also, I end up using locks about once per object. Parallel programming is not something to be feared, but embraced.
- CRAZYSWEETGUY, on 10/12/2007, -0/+0As a consumer and just now find out about this and how it works, it is different than I thought. Most people buying these things do not know that much about these. I was thinking that dual core processors mean that both processors would run at the same time on the same application, not one processor doing one thing and another processor doing another thing. I was thinking that they could not make the processor bigger (moore's law) so they chose to just combine them instead to make the speed much faster. From reading this thread I have found out that each processor would do a task of its own preventing the other tasks from being held up if one is taking a lot of system resources (also prevents system lockups so that there is still a processor to do the other tasks) and the software needs to have programs writting to allow more than one processor to do one task. This is what will solve the speed limitations of each task.
- maninblac1, on 10/12/2007, -1/+1Try computer science and software engineers, CpE's don't have that much to do in the software world, CpE's are alot closer to EE's than they are to CS's. The extent of CpE's software programming is firmware and drivers, Firmware naturally won't be multi-threaded, and most hardware applications only need a single thread except graphics and maybe audio.
I'm a CpE and these are the things we learn. - tuxidomasx, on 10/12/2007, -1/+1i'm a CPE too.
and it really depends on the specific CPE program. most CPE programs require a mix between EE and CS courses (with some unique CPE courses thrown in). As you know, this gives people the ability to have a stronger concentration toward either field. A few of my CPE friends lean so much toward software that they could handle any software engineering job easily (they took the minimum amount of EE classes and maximized their number of CS classes).
Thats why i claimed that CPEs could benefit by learning FP languages-- i was mainly referring to those who are more software-oriented. - Insolence, on 10/12/2007, -1/+1http://www.duggmirror.com
- succubuskiller, on 10/12/2007, -2/+2I agree completely. Though you may not have one application that is benchmarked to be much faster, but the overall system experience will run faster since just as it was said above, other tasks are delegated to other cores and do not run into needing to be scheduled for time on the cpu.
Of course with some applications may want access to all 1-N cores since it will help processing such as video editing. Items such as Web browsing or email do not require parallel processing to achieve a satisfactory run time or running Word. I would say that it won't be a very huge amount of programmers which need to try to add parallel processing to their programs. - khrome, on 10/12/2007, -1/+1I think what was taken issue to by others is:
1) the assertion that a compiler can genericly parallel-ize code written for linear execution.
If you think this is a simple idea, think about the side-effects of trying to predictably re-simulate something based on pseudo-random input seeds and trying to keep those seeds synchronized so that a given input produces the same output through multiple threads use of a particular random generator.
2) the fact that you use 'codes' as plural for code. I may be wrong about this but for me code has always been both singular and plural. Perhaps this is slang, but it's pretty well accepted, at least in the circles I travel. - kledge, on 10/12/2007, -3/+3That Policy is Still in effect and yes if you run Windows 2003 server on a quad core u will need 2 licenses because the Microsoft server software is licensed on a per proccesor basis not a per installation as is XP Pro and XP Home
- LaughingMan11, on 10/12/2007, -2/+2The problem isn't so simple as you describe. While those are the steps to protecting critical sections and shared objects, the challenge in parallel computing is coming up with something that maximizes parallel performance.
I could come up with a parallel version of an program that is 10 times slower than a single threaded version of that program because it lets too many of the threads idle waiting on shared resources...
Coming up with a decent parallel algorithm is challenging... depending on the complexity of the problem you're trying to solve, it can be damn near impossible to get better performance than single threaded. - edalquist, on 10/12/2007, -3/+3Like you said, the big this isn't as much single app performance increases right now. Those will come now that we have multiple cores. The big thing is we have massively multi-threaded and multi-process environments on our desktops. Having multiple cores to deal with all these tasks makes computers very visibly more responsive.
As for multi-threaded programming, most software engineers worth their salt should be able to design at least basic multi-threading into the app (each big task runs in its own thread). Granted splitting up things that appear to be a single threaded task into multiple threads is very complex but that isn't really needed yet. The software will catch up to the CPU capabilities (I'm sure the same articles would have come up for SSE, MMX, MMX2, etc..) the software developers need the hardware there to justify the effort.
As we go down this road I can really see some cool advances. Really splitting out gaming apps into multiple threads (perhaps one for AI, one for physics, one for network communication, etc..) and it appears more games are already going down that route.
As others have said, these articles are just FUD spread by people that run their single thread bench mark against the multiple cores and get all up in arms because they don't understand the use cases and possible advances. - tuxidomasx, on 10/12/2007, -1/+1Colleges should make more of an effort to add a course in functional programming to the curriculum for computer science and computer engineering majors. Due to multicore processors, the ability to write pure functional code (which is naturally parallelable) will become a desireable skill. But currently, its often overlooked at many (if not most) of institutions.
- inactive, on 10/12/2007, -4/+4I found that even things I didn't expect to get a speed boost, got one when I went dual core.
Just the simple example of the OS doing its stuff on once core and the other core being used for applications made a tangible difference.
Of course, when the quad core chips come out, we'll see basically the same speed as we have today with dual core chips unless applications are rewritten. - xLGx, on 10/12/2007, -1/+1The title for this digg is rather misleading.
- inactive, on 10/12/2007, -1/+1There are tools that help with this today, such as OpenMP.
OpenMP is not all it's cracked up to be, you still need to partition your app to be multithreaded (so the OS can schedule it on multiple cores). OpenMP *can* offload some repetitive loops that have no data dependency.
You then need to worry about whether or not shared data is cached across the cores. multi core systems usually have a shared L2, but dual processor dual core systems often do not share a single L2, which means data locality makes a huge difference.
The key to MP systems is partitioning your app properly and getting your shared data locks right and making sure you make good use of your caches.
It's not as easy as writing single threaded code, but who on earth is doing that these days anyway ? - Giga, on 10/12/2007, -2/+2I was under the impression it was based on the number of CPUs, not cores. A single core, 2 socket design requires 2 licences but a dual core, single socket design only requires one licence (and in theory performed about the same).
- oriondr, on 10/12/2007, -1/+1lol, Buried for truth.
C++.NET isn't the microsoft version of Java, where the hell do you get your opinions from?
C# is said to be the MS equiv. of Java, not .NET, at least get your false opinions right :P - aagee, on 10/12/2007, -1/+1The premise of the article is total and absolute crap. Programming models involving multiple execution contexts (that execute in parallel) are commonly used and very well understood (e.g. threads, processes). The synchronization issues are the same whether these models are implemented on a single CPU or multiple cores. The implementation of the synchronization primitives themselves is certainly different at the lowest levels - but the OS hides that well enough to make it transparent to the programmer and the eventual user.
- MacFlecknoe, on 10/12/2007, -1/+1@maninblac1
I guess Im in the dark here. I dont see where the problem with multithreading in UNIX is. I use the Pthreads library and it works wonderfully... I prefer it 1000 fold over forking processes.
What are you claiming here? Without including specifics in your post it sounds like youre just this making stuff up or parroting what some "other clueless developer" told you. - Otto, on 10/12/2007, -1/+1I've seen a lot of nonsense recently about how programming multithreaded apps is "extremely difficult". This is a total load. It's not difficult to program multithreaded apps. Making apps thread-safe and multithreaded is extremely easy. The difficult part is making them multithreaded in a way that actually gives a performance boost.
Scientists and people who have been using super-computing for years are generally using that sort of stuff to, basically, do complex math. These sorts of things lend themselves to parallel processes very well, as generally they're doing discrete steps and combining the results at the end. This is why they're been doing it for years, it's something that works well with multiple threads.
Modern applications on home computers don't lend themselves well to multithreading. How is having extra threads going to help your web browser? Or your DVD burner? It's not, these sorts of things are single procedural processes. They have to happen in order or they don't work. Every once in a while in these you can find some chunk of code that you could pop off to a thread to get a minor speed boost, but it's small enough to not bother with. Now, multicore is still useful, because you can run different processes on different cores, and every modern computer runs lots of simultaneous processes anyway, so that's nice.
Where you see the real benefit of multiple cores or multithreading is in any application that does, basically, intense mathematics. Image manipulation frequently involves complex algorithms that can be paralleled. Games could benefit from this too, but might be difficult to convert because it's hard to take an existing single threaded design and convert it into a multithreaded one. There's different design constraints on the two, and they don't mesh much, and game programmers are used to low level hacks to get speed improvement. The idea of improving the higher level design to make the thing massively parallel isn't really in their existing skillset. They've got new tricks to learn, basically.
So, it's not "extremely difficult" to program the stuff. What's difficult is overcoming the mental blocks inherent in single threaded design. It's as difficult of a shift as procedural->object oriented is for some programmers. - LogicallyGenius, on 10/12/2007, -1/+1
I hope JavaVirtual machine is upgraded with each multi core processor release.
I mean if the Virtual Machine takes care of the multicore by having a VIRTUAL PROCESSOR in it then Problem solved. -
Show 51 - 97 of 97 discussions
The Digg Toolbar for Firefox lets you Digg, submit content, and keep track of Digg even when you're not on the Digg site. Download the official 
© Digg Inc. 2009
— Content created and posted by Digg users is