Welcome to our community

Be a part of something great, join today!

Register Log in
  • Hey all, just changed over the backend after 15 years I figured time to give it a bit of an update, its probably gonna be a bit weird for most of you and i am sure there is a few bugs to work out but it should kinda work the same as before... hopefully :)

New MacBook Pro's next week?

Offhollywood said:
CUDA is coming.
Click to expand...
Thats quick to be coming out, since the OS X API beta just came out in August...

:drool:


chocblu said:
I'm a software developer and I dont think that writing software that efficiently uses multiple cores is an easy thing. It really depends on the architechture of how the program was created and also what its used for.

The reason that a lot of software engineers may be waiting for a compiler is that once that is made, the porting of these programs to effectively use multicore is much easier and mush less error prone.

But i think one of the things that needs to be understood, is that some programs just dont lend them selves to parallelism. Some things have to be done one after the other. So not all programs will necessarily benefit form parallelism.
Click to expand...

Indeed, the problem we face now is not a hardware one, but rather it is the software that lags behind. There is no magic code to make your software work on multiple cores more efficiently. Seemless multitasking, where each core handles an appliation so the user can switch between apps without slowdown, is one thing, but stacking all the cores to work on a single process is seriously difficult.
 
chocblu raises a valid point in that not all applications lend themselves to parallelism.

As a developer myself, I understand the challenges of multiprocesor software development. It is not easy, I never said that it was. On the other hand, many of the currently accepted views pertaining to multi-processor systems only apply to systems with no more than 4 or 8 cores, sometimes 16. Mostly it centers on parallelism or splitting applications into various tasks to coincide with available CPUs. This is not the proper approach, nor the one that CPU makers are advocating. Intel and AMD are pushing different software design practices, not new ones, but ones that differ from the desktop computer industry norm and so far it's falling on deaf ears. Or at least with very few exceptions.

Many developers, and consumers too, don't think small enough when it comes to the multi-proc paradigm. It's not about dividing up applications to appropriate cores for multitasking. It's not about parallelism in software design. It's a nodal system in the same way that large compute clusters operate, but on a much more closely-connected level. In just a bit over 10 years, a top-shelf workstation will have as many processors (cores) as we can fit into 42 units of rack mounted blades today. Approximately 320 cores once AMD and Intel reach their 2020 goal of 80 to 100 cores per CPU. Quad CPU at 80 cores = 320... MHz will not increase, memory speeds will increase along with lower latency to accommodate. It will be like having a bladecenter or compute cluster inside your Mac Pro, but better. All cores able to access the same large memory heap and multi-node cache arrays. All nodes interconnected at core clock speeds with bandwidth that leaves fiber channel, NUMA-Link, Infiniband, etc.. miles behind in the dust.

Software design practices for massively multiprocessor systems and compute clusters have been developed and tested over the last 20 years. This is not new. It's a means of adapting one approach to software design to a refined version of the hardware it's designed for. Compilers are not going to do this for the developer. CPU makers and major industry players like IBM, HP and Sun have been saying this. But they're the ones who understand the new paradigm.

At this stage in the game, if designing new software, you should not be designing for a system with 8 cores while anticipating one with 16 cores or thinking of ways to split tasks into defined chunks relative to the number of cores. It should be a massively nodal approach as you would develop specific software for a compute cluster. The number of cores is irrelevent, the software should be able to scale from one core to whatever, or at least until nodal propagation drives inefficiency to an unacceptable level.

So here we are, the future is pretty well defined unless a massive technological breakthrough occurs. CPUs (cores) are not going to get any better or faster. But we are going to get more of them, lots more of them, and the connections between these CPUs and the rest of the system are going to get a whole lot better. If software developers step up to the challenge, then we stand to see a much greater increase in system and software performance than what we all saw with the MHz race.

The industry-wide whining over "it will take a massive re-write" needs to stop. Oh, boo-hoo... It also gets tiring to read / hear about companies doing a "complete re-write" or a "completely rebuilt from the ground up" new version of an application only to buy it and see that most of the same nagging bugs are still there, still no support for 64bit environments, no use of new graphics abilities / GPU functions, etc... Of course, that's an economic problem in some sense. The big software companies move too slowly and have too much dead weight to lug around, the small companies don't feel they can sell enough software seats to justify it. Many new software projects don't focus on doing it the best, most forward-thinking way possible. They focus on getting the software made and shipped in a form that works pretty good as it is on today's hardware.

New hardware is here with drastically new and changed hardware just around the corner. Time for a shift. RED did it with a cinema camera. It's time someone did it with editing / media software. And someone do it for CAD, ...for publishing, etc..

If I had the means to set up shop and do it right, I would jump right in and give it a try. I'd probably target the database market myself, but maybe go for editing / finishing. ...Maybe I'll buy a lottery ticket for the drawing this weekend. :wink: But I don't think that $15M would be enough, especially after Uncle Sam takes his cut.
 
Well, now it is official that Apple will reveal the new laptops next tuesday. Some rumors suggest 13" MacBooks going for under thousand bucks.
For more rumors/spoilers go to http://www.appleinsider.com/articles/08/10/09/sources_latest_macbook_pro_photo_is_the_real_deal.html

Also: "expecting a complete redesign of the 15- and 17-inch MacBook Pros, which are likely to carry an $1899 entry-level price tag. Among the new models' selling points will be a thinner design and more sophisticated gesture-based touchpad" http://www.appleinsider.com/article...ys_new_macbooks_could_be_priced_from_899.html
 
I still want quad-core, 8gb and blu-ray. Oh, it would be nice to have higher-res displays too. Dare I wish for a numeric keypad on the 17" like most every other 17" notebook has?

I'm expecting the MBP to be upgraded with new nVidia GPU, eSATA and/or FW3200.
 
2.8 GHz processor, nVidia 9400 GPU with HDMI output
17" 1920x1200 widescreen LCD with matte finish and LED backlighting
FireWire 3200
SSD available as BTO option

I wouldn't count on Blu-ray until they update the DVD Player app and DVDSP / iDVD.

EDIT: Looks like there may be Blu-ray support afterall!

http://forums.macrumors.com/showthread.php?t=578620
 
Jeff Kilgroe said:
Apple could learn a few things... So could Microsoft and the Linux community. Current thread and process scheduling in mainstream OS's isn't anything special.

Beyond that I know of very few applications that actually make efficient use of multiple CPUs (cores). Note the key word here is "efficient". Redcine renders will max out an 8 core Mac Pro, showing all 8 CPUs continuously loaded to 80% or higher in the CPU meter, but it's hardly efficient. It's spinning its wheels in the mud. I can restrict Redcine to run on only 4 cores instead of all 8 and it hardly has any effect on render speed.

That was just an example. Apple could learn, Adobe could learn, Autodesk, Luxology, etc.. Even systems that have a long history of multi-CPU support like 3D applications typically only do so for rendering operations. It would be nice if the multithreaded support could be translated to particles, dynamics, boolean constructs, etc.. Kinda sad that with all this power under the hood of a workstation these days, we still have to work on something else while ParticleFX in Lightwave grinds away on one CPU core for an hour when it could be theoretically done in less than 10 minutes.

Over the next few years, both AMD and Intel are going to be pushing the multiprocessor paradigm. CPUs have essentially reached their limit in terms of MHz and overall efficiency of the x86 architecture. Intel stresses this with nearly every announcement relating to multi-core CPUs and developer notes. Yet software developers are still slow to adapt. It's like they all just seem content to keep waiting it out until compilers are capable of doing it all for them -- not going to happen. Even game developers, who are usually at the forefront of using new hardware, hare pulling up lame on this one. The hot new thing after using multiple GPUs (tell me again why they can't use multiple CPUs as well?) is the new physics / dynamics CPU cards. Or a "GPU" for simulated interactions. Well, that's cool, but what's the point of the add-in card when most new gaming PCs are quad-core boxes and most games are leaving 3 of those cores mostly un-tapped. Oh wait... It's because these add-in card makers have essentially lobbied game developers to support the hardware so they can sell it, even bundle it with hot new game titles.

Yes, it's true there are some applications that will load up an 8 core box, some even do it well (Mental Ray). But I won't be so excited to see upcoming 16-core workstations when most software can't even scale beyond 2, maybe 4 cores in most situations.
Click to expand...

Makes you kind of wish for the old days, when the hardware came with the software as a package so the coders could max out the efficiency to perfection. I guess some of the very high end systems from Autodesk may still do this. Now with so many layers of software and operating systems, I guess it's not as profitable to perfect it.
 
From Gizmodo (insider joke)

From Gizmodo (insider joke)

apple-brick_01.jpg


And from Joy of Tech:
1160.gif
 
You must log in or register to reply here.
Back
Top