And the current thread per task, thread per CPU core mentality that many programmers have is not the proper way to approach this.įor something creeping up on 15 years old, that thing is in fantastic shape. So start planning and figuring how to micro-manage threads and fibers within your code because we'll be hitting 16 to 24 cores by 2010 and MHz per core isn't going to creep much past 3GHz. Both Intel and AMD are predicting 80 to 120 cores being the max for the x86 architecture. But this is the way it's going to be for a while and eventually we'll hit a core barrier, just as the MHz barrier popped up. They have been resisting it for years as anyone who has run multiprocessor systems over the years will attest to. I don't think the software industry has really warmed-up to the multi-core paradigm just yet. And then the cycle starts again in 18 months when 12 or 16 core chips start shipping. Once a new system is released, it should be a minimal effort to test and tweak the software for the new system and quickly release an update, thus making their customers only wait a week or two from when the systems first ship as opposed to several weeks/months while much of an application is re-written to accommodate 8 cores since the last version was hard-coded to handle 4. Programmers should make the effort to accommodate upcoming multi-core designs into their software development cycle. Too bad Apple doesn't make pre-release hardware available via higher-level ADC programs, only a select few get the priviledge. Engineering samples started shipping several months ago (early september, IIRC). In other words, it's no secret that this hardware is coming, we've known about quad-core clovertown CPUs for nearly a year. There's no reason software isn't being planned for the upcoming CPU architectures and newer versions being developed to handle such. What do you prefer: Unpack 8 core Mac Pro, install Handbrake, run it, 50 percent CPU usage, or unpack 8 core Mac Pro, install Handbrake, run it, kaboom!īeing a developer with a fair bit of graphics programming and multithreaded development experience, I would say the solution is somewhere in-between. Are you seriously suggesting that a developer should ship a product with features that are not only untested, but haven't even been tried out?
0 kommentar(er)
