Dunno, does the stackless modification remove the GIL? If it doesn’t, then the tasklets still run in a single thread.
Erlang fanboys think their software uses multiple cores, but in fact you need to have multiple Erlang interpreter processes running to do that.
Failed troll is failed, the Erlang runtime is natively multithreaded since the release of R11B-0 in May 2006. Since that time, the runtime automatically spawns a thread per core (default, you can ask for more or less) and dynamically maps your erlang processes on the OS threads.
You should update your knowledge before trying your trolls.
You didn’t review any web browsers! The majority of the time that I’m on my computer, I’m in Firefox.
I often open 5, 15, 30 or more tabs at once, after which Firefox becomes extremely unresponsive for several seconds. By far the most slowdown and unresponsiveness I ever see is in Firefox, from opening lots of tabs at once.
If more cores can help this situation, it’s a definite plus for me!
As other people have pointed out, the build system for VC++ 2008 will build multiple targets simultaniously. Here’s an article on Valve using multiple cores. http://arstechnica.com/articles/paedia/cpu/valve-multicore.ars
executive summary:
Even if you don’t do anything special, you get some benefit, because your subsystems often run in multiple threads.
The graphics subsystem can really benefit from multiple cores. Other subsystems less so.
A side benefit is that the rest of the game gets more CPU, so you can have a more complex AI.
The practical max right now is 4 CPUs. More than that, and you’re running into memory starvation issues.
Jeff wrote:“The numbers are correct; it’s a bit confusing because some units are larger-better, others are smaller-better.”
Maybe you should add the units to the numbers in your post, otherwise people have no way of knowing what those numbers mean without looking at the original article.
Even without intelligently-threaded applications, I think most users can make good use of dual-core desktops simply due to multitasking. Quad-cores definitely take more work to utilize, but certain classes of users could definitely use this… video editors, web developers, and other types of programmers and creative professionals often have several distinct intense processes at once.
It’s only a matter of time until all applications are written to take advantage of multiple cores, in which case we’ll probably see a leap in software engineering. Maybe the Windows of the future won’t take an eternity to boot anymore?
I should think you could occupy even more than 4 cores in game programming.
It’s going to take some serious talent to harness the multitude of threads that will be available in the future and then apply them to multiple GPUs. Of course most people won’t have SLI or Quad-SLI setups, but I think someone somewhere should write a “Super Game”(read up on your Nietzsche, kids) to demonstrate the shear power available without worrying about scalability across single cores. I bet John Carmack would do it, he already has enough Ferraris so he doesn’t have to worry about sales volume.
AMD vs Intel - IIRC AMD “Barcelona” is “true” quad core, current intel “quad” cores are two two core units in one package, typical intel/microsoft-style marketing-over-technical trickery.
Also, AMD quad core opterons will support nested page tables, making virtualization perform significantly better. Thus, if you want to play with virtualization, getting a quad core AMD might be your best short term option.
I test my own OS and play around with other OS’s in emulators all the time. I’m only on a single-core CPU at the moment (to upgrade means new everything, pretty much) and a friend with a dual-core allowed me to try some emulation on his system.
First thing I noticed was the difference moving the emulator’s process onto the second core (via task manager’s “Set Affinity” option) made to the running of the rest of the system. Note that this isn’t Virtual PC (which can run at very low CPU usage), these are emulators such as Bochs, QEMU and PearPC, all of which enjoy eating up valuable CPU time.
Why look at today’s programs performance with tomorrow’s cpu setups?
It’s almost pointless to worry about multicore performance in standard apps at this stage of the game. One can’t just go back and “add in” support for multicore in any significant application, beyond trivial stuff that can be stuck in a background thread (which should be done already, for UI interactivity).
To really see the benefit of multicore, applications will not only have to be largely rewritten, but devs will have to start thinking in a completely different way. Not just in a “how can we thread this algorithm” way, but in a “what should we pre-emptively compute just in case the user wants it” way. The latter is where multicore starts to make sense, but it’s much harder than the former (which is already pretty hard). As far as I know, the only people really thinking about this are at Microsoft Research…
Regardless, massive redesigns won’t be justifiable to the shareholders until everyone has the multicore systems. It’s chicken-and-egg. Hence, it’s our job as forward-thinking developers to convince everyone we know to buy N-core over (N/2)-core, so that we’ll have more cores to play with.
Remember, more cores == more awesome. For the children.
I don’t consider perfomance tests run in a vacuum to be a great measure of true performance.
I would think running the tests while listening to music, surfing performance tuning sites in I’d, outlook periodicly checking for mail, an im chat app running, sidebar full of gadgets, and a task bar of the normal bloat ware (adobe or steam) would be a better representation of the perfomance gains.
