Welcome to our community

Be a part of something great, join today!

  • 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 :)

When is apple releasing 12 core Mac Pro?

The chip's being released in March for PCs. Since the Mac Pro is due for an update anyway, I'd say chances are 100% we'll get an Apple announcement soon.

Heck, they could announce now and take preorders if they wanted to do it that way.

Bruce Allen
www.boacinema.com
 
Why all the fuss about faster machines when Snow Leopard still isn't up to par? We're still operating in 32 bit. Yes, you can switch to 64 but with a minimal amount of apps. Machines are fast as hell, it's now time for software to catch up.
 
And since most all software out there, including our beloved RED tools, do a really poor job at multithreading and supporting multiple CPUs, there's not a whole lot of incentive to run out and buy a 12-core system. The only apps that really leverage the power are rendering applications that can specifically divide up tasks amongst the CPU cores. So RedRushes will benefit, RedLine will benefit with a good render management software...

The software industry has been stuck in a rut for the past few years and it's getting real old now. I can understand 32bit and backward compatibility for certain apps.. But for pro applications that are supposed to leverage the power of new technology, one would think that complete 64bit re-writes with highly-nodal, multithreaded code would at least be starting to show up. But no. It's not. All we have is a few rumors about 64bit versions and a confirmed 64bit version of Logic Pro coming soon. In other words, Apple, Adobe and many others are going to ride the 32bit horse, that can only half-ass scale to 2 CPUs, for as long as they can. Which translates into: until sales numbers on the next 32bit update fall by 60% or more, no one is going through with the full re-write. And even then, the few who are starting this process are just going 64bit and are trying to leverage GPUs, which are as varied and short-lived as can be, rather than designing an app that can scale efficiently from 2 to 32 CPUs. I'm not saying that GPU's shouldn't be used, they should, but they're only one piece of a large puzzle here. And there are few things more frustrating than getting some fresh new beta software that didn't exist only a few months and is designed for a professional computing audience, yet it's still compiled for 32bit space and I have to sit and wait for it to process when I'm on an 8-core nehalem box... I watch the CPU meter peg itself at 100% on CPU-0 and push CPU-1 to about 30% and the rest sit idle. Yay... Go back to the drawing board... please.
 
Totally agree Jeff

Totally agree Jeff

Having spent a big chunk of my time tilting at the 64 bit windmill in a previous life all I can say is amen. And the average program isn't written to utilize multiple cores to any reasonable extent. Given that this stuff has been around for more than a decade (anybody else remember the alpha processor?) it's really rather pathetic.

These are all software problems.

The hardware issue I'd like them to address in PCIe slots / throughput.

I know I'm not alone in having cards designed to run at 8 or above stuck in a slower lane, and power draw across the bus is maxed out as well. And while we're at it lets get the ipass connector or equivalent back in there so an internal raid isn't such a pita.

While I'm dreaming can I add room for a couple more drives, usb 3, and an e-sata port?

Given I have all of the above in the pc case sitting next to the MacPro, and the PC has blu-ray RW as well, I'm reminded daily that while I love my Mac...

It's hardly cutting edge.

I'm serious about those PCIe slots, sadly I'd probably upgrade just for that.

Steve
 
CS5 will be 64 bit. At that point the only professional App which I'll not be running 64bit is quicktime. And I use the word professional in that context with a huge set of ironic quotation marks.
 
CS5 will be 64 bit. At that point the only professional App which I'll not be running 64bit is quicktime. And I use the word professional in that context with a huge set of ironic quotation marks.

What in the world was wrong with QT7? It works flawlessly! Able to export, set I/O, etc...
 
What in the world was wrong with QT7? It works flawlessly! Able to export, set I/O, etc...

Either I'm seeing a ton of sarcasm or your definition of flawless is quite different than mine. If it were flawless, it would't have gamma issues to start with...
 
I love QuickTime 7, I use it's quick and dirty editing features daily. The gamma issues were annoying, but easy to compensate for. The foundation of QuickTime X might be vastly improved, the the UI is a joke.
 
honestly...

honestly...

I think it is a generational shift.

The programmers that are stuck in the old ways will/are retiring
or moving into different positions and "hopefully" the new kids will
have the mindset to be able to really program and push boundaries
so that advances can be made.

No insults... just that I think the type of programming that we
are talking about, to be executed day in and day out (from now on);
really needs fresh people and fresh minds, who see the new
geography of code set out before them.

I guess I would liken it toward learning to use the gestural interface
of Maya when it first came about, having used Power Animator/Alias
Wavefront before it. It took a while to rap my head and thought process
around it. But boy once I did, I could see the benefits.

I would say I saw this "G" shift in graphic design in the early 90s, Computer
Animation in the end of the 90s, and now this need for it to happen in
consumer programing apps.

Adobe seems to have struck first, in any real way (barring the heavy
iron guys).
 
Either I'm seeing a ton of sarcasm or your definition of flawless is quite different than mine. If it were flawless, it would't have gamma issues to start with...

No not at all. Besides the gamma, I think QT was fine. I use QT for quick exports and this feature is disabled now.
 
No not at all. Besides the gamma, I think QT was fine. I use QT for quick exports and this feature is disabled now.

Nope, sorry. Lots of issues.

What about support for full-range 0-110 IRE YUV conversions to RGB? Oh, right, you obviously didn't want those top ten IRE of data, let me just clip those off for you...

Quicktime is garbage, and the Achilles heel of the whole FCS system.
 
I think it is a generational shift.

That's what I thought about 8 years ago and was still an industry apologist for only 5 years ago. Now I come out swinging and say it like it is. The entire software development community, on a global scale, needs a swift kick in the ass.

We can talk about all the old programmers or whatever and the need for fresh blood, but I can't agree with that. None of these concepts are new. None of the languages are new. Multiprocessor and distributed computing practices have been around for decades. The hardware is right there under our noses. Just have to use it. And it's hard to tell a lazy programmer that he needs to increase the complexity of his code by a few orders of magnitude when for the past 25+ years, the x86 desktop computer world has become accustomed to their CPU speed doubling every 18 months. I don't think the software industry as a whole has bought into the warnings of the CPU technology being at a plateu and that further MHz increases are not happening. From here on out, the amount of processing power will increase by adding more processors. No direct offense to lazy programmers, I'm one myself... And spent several years as a game developer.

In 5 years from now, when I have a 32-core desktop system and I can still have time to make a sandwich while Lightwave or Maya performs a complex boolean operation because it's limited to one or two CPUs, I'm not going to be a happy camper. OK, I already feel that way now... Oh yeah, it's time for lunch, let me have the particle system solver calculate that new dust effect I've been working on... Maybe it will be done by the time we come back from lunch. Oooh, look at it go, CPU-1 is pegged to the max. :badputer:
 
Here's the problem. Most programmers are dullards who slept through 4 years of college writing assignments and playing video games. There's a reason they call it a CS degree. Many programmers have as much creativity as your average x86 processor. They've memorized a few tricks and become very efficient at shoe-horning what they know into existing situations with minimal thought of how something works. They're really good at solving tiny problems but very bad at solving architectural problems.

This isn't going to ever change. This isn't a generational thing that's just going to slip away. It's the nature of the beast because programming often attracts people who like solving little problems instead of big problems and because the volume needed to produce modern software means to some degree you simply can't get enough extremely talented and super creative people to make the real breakthroughs necessary in many areas to employ multi-core processing. A lot of these solutions need to be made at an almost academic not pragmatic level. What the industry I think is waiting for is a small group of really creative and ahead of the curve developers to write the tools to make writing multi-core invisible to the programmer.

Multi-Core right now is where real-time 3d graphics were 25 years ago. Everybody is individually solving each 3D problem one at a time all by themselves. The extremely talented and creative developers are finding new and innovative solutions but those solutions take time to dissipate into the collective consciousness and even then it only solves one problem. OpenGL and DX however provided a means where the work to make things go fast was left to the standard developers and the unwashed masses just needed to tell it where to go and what to do.

It's up to AMD, Intel and Nvidia (and many smaller companies now) I think to find the best and brightest who can solve the problem in a general high-level fashion so that even someone with my programming skill can just write it and let the compiler deal with it.

A good analogy is the Renderman Language or the new proposed hardware standards Optix and Caustic's OpenRL. You write the shader. You let the PhDs and visionaries figure out how to make it run fast on multiple platforms/hardware/cores.
 
Here's the problem. Most programmers are dullards who slept through 4 years of college writing assignments and playing video games. There's a reason they call it a CS degree. Many programmers have as much creativity as your average x86 processor. They've memorized a few tricks and become very efficient at shoe-horning what they know into existing situations with minimal thought of how something works. They're really good at solving tiny problems but very bad at solving architectural problems.

So true. I taught a Programming 302 class a couple years ago at a local community college. I found myself continuously dumbfounded by the code I was seeing. I'm not claiming to be an expert by any means, but damn... I would just shake my head in disbelief. Like I said, I was a game developer a while back, primarily console games -- Sega Saturn, PlayStation, DreamCast, PlayStation2, Gameboy Advance. I did some work on graphics code, but most of my work was at the hardware level on the back-end. I eventually moved more into 3D graphics, interface design and away from writing code all day long. Haven't done a whole lot of programming over the past few years so I'm a bit out of the loop on a lot of the newer SDKs and toolkits. Especially in the Windows world.

Although, I've done a bit more over the past 8 months or so, dabbling mostly with OSX and iPhone development. I may be teaching an iPhone development at a local tech school this summer. I'm not really sure how I should feel about that yet and I haven't formally accepted the job.
 
Last edited:
Back
Top