|
|
All the news now and in your digital future
Uh Oh! Not Good...
Posted by Dan Brockett
|
Re: Uh Oh! Not Good... February 18, 2010 09:22AM |
Moderator Registered: 18 years ago Posts: 6,730 |
|
Re: Uh Oh! Not Good... February 18, 2010 09:28AM |
Registered: 16 years ago Posts: 542 |
|
Re: Uh Oh! Not Good... February 18, 2010 09:43AM |
Moderator Registered: 16 years ago Posts: 3,410 |
Okay, a couple slightly less sarcastic replies.
That's true. But remember that at its core, Mac OS X is thirty-year-old code. I don't mean some of the underlying design principles and stuff; I mean that a big chunk of Mac OS X consists of source code that was physically typed by somebody in the late 70s, early 80s, and has not been changed since. The fact that some or a lot of the underlying source code is a decade old does not mean that source code has gone off and needs to be thrown out before we all catch salmonella.
For another data point, Media Composer was developed in the late 80s and hasn't been ground-up rewritten since. And though it debuted on the Mac, it wasn't even originally a Mac application! It was originally written to run on workstations built by a company nobody even remembers any more. Along the way, Media Composer has been modified to run on the Power PC, on Intel computers under the Windows OS and on Mac OS X. By all rights, it should be a wonky, unstable piece of junk ? but from what I've heard, the universal opinion is that version 4 is the best version yet.
There's an old saying about babies and bathwater here, but I can't remember how it goes.
Let's break these down individually.
"Make it 64-bit" is a damn tricky thing. Back in the 90s, I worked primarily on SGI systems, workstations and mini-supercomputers. Those were among the first widely available 64-bit systems, and SGI did something very clever with them. Knowing there was a huge (in relative terms) installed base of software that'd been compiled against the 32-bit MIPS ABI, SGI made sure their 64-bit systems would run all that older 32-bit code without modification. (This was an approach Intel famously failed to take with their Itanium line of high-end chips, and they failed commercially as a consequence.) But in doing so, they discovered something that's only obvious in retrospect: All other things being equal, a 64-bit version of an application will run slower than its corresponding 32-bit version.
It's easy to see why. A 64-bit application can address tons more memory, because it uses 64-bit-long memory pointers ? essentially just logical addresses to places in memory ? rather than 32-bit pointers. But a lot of what computers do is store and recall pointers, so pointers end up in processor cache all the time. Like literally all the time; a typical user-facing application does way more with pointers and handles (pointers-to-pointers) than it does with user data.
And 64-bit pointers are (surprise) twice as big as 32-bit pointers. Which means you can only fit half as many of them in the various high-speed caches in your computer. Which means you have more cache misses, and cache misses are really expensive in terms of computer performance. Even though it's measured in microseconds takes a lot longer to fetch a number from main memory than from cache, and when you're doing that a billion times a second, it adds up.
So for about a decade, the conventional wisdom was that 64-bit computing was sometimes necessary ? when you needed to manipulate large data sets in memory ? but never desirable.
Intel (and others, but we're all using Intel microchips right now) did some clever things to try to combat that. It took them years of trial and error, but it's to the point now where 64-bit Intel microchips like the ones in our Macs can be as fast or faster when running 64-bit code compared to otherwise-equal 32-bit code. But 64-bit is still not an automatic "turbo" button, and "Let's make it 64-bit" is not a good business choice. A good business choice is "Let's make it 64-bit so we can do X."
As for memory, Final Cut doesn't need much. Seriously; Final Cut sips RAM. That's because it rarely needs to have more than twelve-or-so frames in memory at any given time. The whole design philosophy behind a Final Cut system is to have a storage array that's fast enough to provide the computer with frames in real time. Because of this, Final Cut doesn't need to do a ton of complex caching in main memory, even when doing real-time playback of unrendered effects. Compare this to an application like After Effects, for example, that uses main memory to cache rendered frames instead of writing them to disk, to provide real-time playback in a context where real-time playback is otherwise impossible. Or say Photoshop, where your entire raster is resident in main memory at all times, every pixel of every layer stored as a vast list of numbers. For those applications, an effectively unlimited memory address space is an automatic win; for Final Cut, the benefits aren't remotely so obvious.
On the subject of multi-processing and GPU offloading, Final Cut is actually rather brilliant. It's a highly modular system, code-wise, you see. Final Cut does no decoding or encoding itself. All of that is handled by Quicktime, and each Quicktime component for each separate format is a separate piece of software. That opens up the possibility for high levels of optimization at the Quicktime-component level, to take advantage of parallel architectures. This isn't merely theoretical; this is how ProRes works. One of the major selling points of ProRes when it debuted (and in turnabout, one of the major selling points of the eight-processor Mac Pro systems when they debuted) was the fact that real-time performance with ProRes scaled linearly with processor count. The Quicktime component for playback was highly optimized for the Mac Pro, and thus could play back roughly twice as many streams in real time on an eight-processor system as on a four-processor system. Linear scalability is the holy grail of parallel computing, and Apple came about as close as humanly possible to achieving it with ProRes and Final Cut 6 ? without making any major parallelization-related changes to Final Cut itself. It was all in that one module.
Similarly, the Smoothcam feature that was a major selling point of Final Cut 6 (it was 6, right?) is implemented as a plug-in. It wasn't necessary for Apple to rip out big chunks of the application to add that feature; they just implemented it as a plug-in and went on with their lives. This had the advantage of leaving the core application basically untouched, as far as the Smoothcam feature was concerned, which meant it was both easier to implement and less likely to introduce regression bugs in the application itself.
Does that mean Final Cut is perfect? Of course not! Even aside from the fact that there's always room for improvement in everything, there are some really obvious opportunities for improvement in Final Cut as it stands right now. The rendering engine could stand to be modularized, like playback and effects are today. If Final Cut wants to be a viable finishing system (which is not necessarily the case, but go with me) then the focus needs to be on ubiquitous real-time performance. Final Cut needs a real-time color corrector, real-time DVE, and at least two layers of real-time compositing. We're a long way from that; right now, Final Cut can't even consistently do real-time dissolves with full-resolution media. Dissolves! That's the simplest thing an editor can do! The focus for the Final Cut engineering team, in my just-some-random-guy opinion, needs to be on eliminating "render" as a thing the operator needs to know about. Will they ever succeed entirely? Of course not; inevitably, somebody's going to decide he wants to use Final Cut as a full-fledged 3D compositing system (sigh) and will try to stack up twelve or sixteen layers on the timeline and be dismayed to see the giant "Are you kidding?" error box pop up. But a reasonable goal should be to make eighty percent of what eighty percent of editors do be real-time.
Will they ever achieve that? No. I really don't think they will. You want to talk about GPU? Okay. When Autodesk ported Smoke to the Mac, they declared unilaterally that the only supported graphics option would be the eighteen hundred dollar QuadroFX board. Smoke won't run at all without that board. The technical reason revolves around backpath performance and drawing rendered frames back off the board and into main memory, but whatever. Point is, if you want a real-time system, you have to pay for it in two ways: first, by giving up the flexibility to just install the software on pretty much any computer you have lying around, and second by handing over lots of pictures of George Washington to get the right gear.
It sucks, but there's a lot that the graphics card in your Mac Pro just isn't useful for when it comes to Final Cut. Could the software take better advantage of graphics cards in general? Sure! OpenCL provides a robust software framework that opens up the possibility of offloading processing tasks to the graphics coprocessor ? or indeed, any other coprocessor, in principle like the Red Rocket board for R3D coprocessing ? and it'd be great if Final Cut took advantage of that. But the unhappy truth is that graphics boards aren't ready yet to be used as general-purpose processing nodes. There are still too many shortcomings ? like the aforementioned backpath performance ? that were never relevant as long as the graphics board's job was to do nothing more than take OpenGL instructions and textures from the computer and turn them into a raster. OpenCL lays the groundwork, but it's still up to the IHVs to do their part.
Snow Leopard, as I mentioned before, marked the public debut of a couple of fundamental core technologies ? GCD and OpenCL ? that have the potential to radically change the way high-performance software is written. But big changes happen slowly. Not this year but possibly next, and almost certainly by mid-2012, we'll see Final Cut Pro 8. Don't be surprised if at that time the software has been enhanced by these underlying core technologies to emphasize real-time performance. It just can't all happen overnight, y'know? And you're certainly not more likely to get it sooner by imploring Apple to discard all the work that's been put into Final Cut
Quote
FCP, at it's core, is 10yr code
That's true. But remember that at its core, Mac OS X is thirty-year-old code. I don't mean some of the underlying design principles and stuff; I mean that a big chunk of Mac OS X consists of source code that was physically typed by somebody in the late 70s, early 80s, and has not been changed since. The fact that some or a lot of the underlying source code is a decade old does not mean that source code has gone off and needs to be thrown out before we all catch salmonella.
For another data point, Media Composer was developed in the late 80s and hasn't been ground-up rewritten since. And though it debuted on the Mac, it wasn't even originally a Mac application! It was originally written to run on workstations built by a company nobody even remembers any more. Along the way, Media Composer has been modified to run on the Power PC, on Intel computers under the Windows OS and on Mac OS X. By all rights, it should be a wonky, unstable piece of junk ? but from what I've heard, the universal opinion is that version 4 is the best version yet.
There's an old saying about babies and bathwater here, but I can't remember how it goes.
Quote
so it can take advantage of things like being 64-bit, being able to access more RAM (I think 3 or 4 gigs is the limit right now), being able to better leverage all the cores the Mac Pros have, take more advantage of the GPU, etc.,.
Let's break these down individually.
"Make it 64-bit" is a damn tricky thing. Back in the 90s, I worked primarily on SGI systems, workstations and mini-supercomputers. Those were among the first widely available 64-bit systems, and SGI did something very clever with them. Knowing there was a huge (in relative terms) installed base of software that'd been compiled against the 32-bit MIPS ABI, SGI made sure their 64-bit systems would run all that older 32-bit code without modification. (This was an approach Intel famously failed to take with their Itanium line of high-end chips, and they failed commercially as a consequence.) But in doing so, they discovered something that's only obvious in retrospect: All other things being equal, a 64-bit version of an application will run slower than its corresponding 32-bit version.
It's easy to see why. A 64-bit application can address tons more memory, because it uses 64-bit-long memory pointers ? essentially just logical addresses to places in memory ? rather than 32-bit pointers. But a lot of what computers do is store and recall pointers, so pointers end up in processor cache all the time. Like literally all the time; a typical user-facing application does way more with pointers and handles (pointers-to-pointers) than it does with user data.
And 64-bit pointers are (surprise) twice as big as 32-bit pointers. Which means you can only fit half as many of them in the various high-speed caches in your computer. Which means you have more cache misses, and cache misses are really expensive in terms of computer performance. Even though it's measured in microseconds takes a lot longer to fetch a number from main memory than from cache, and when you're doing that a billion times a second, it adds up.
So for about a decade, the conventional wisdom was that 64-bit computing was sometimes necessary ? when you needed to manipulate large data sets in memory ? but never desirable.
Intel (and others, but we're all using Intel microchips right now) did some clever things to try to combat that. It took them years of trial and error, but it's to the point now where 64-bit Intel microchips like the ones in our Macs can be as fast or faster when running 64-bit code compared to otherwise-equal 32-bit code. But 64-bit is still not an automatic "turbo" button, and "Let's make it 64-bit" is not a good business choice. A good business choice is "Let's make it 64-bit so we can do X."
As for memory, Final Cut doesn't need much. Seriously; Final Cut sips RAM. That's because it rarely needs to have more than twelve-or-so frames in memory at any given time. The whole design philosophy behind a Final Cut system is to have a storage array that's fast enough to provide the computer with frames in real time. Because of this, Final Cut doesn't need to do a ton of complex caching in main memory, even when doing real-time playback of unrendered effects. Compare this to an application like After Effects, for example, that uses main memory to cache rendered frames instead of writing them to disk, to provide real-time playback in a context where real-time playback is otherwise impossible. Or say Photoshop, where your entire raster is resident in main memory at all times, every pixel of every layer stored as a vast list of numbers. For those applications, an effectively unlimited memory address space is an automatic win; for Final Cut, the benefits aren't remotely so obvious.
On the subject of multi-processing and GPU offloading, Final Cut is actually rather brilliant. It's a highly modular system, code-wise, you see. Final Cut does no decoding or encoding itself. All of that is handled by Quicktime, and each Quicktime component for each separate format is a separate piece of software. That opens up the possibility for high levels of optimization at the Quicktime-component level, to take advantage of parallel architectures. This isn't merely theoretical; this is how ProRes works. One of the major selling points of ProRes when it debuted (and in turnabout, one of the major selling points of the eight-processor Mac Pro systems when they debuted) was the fact that real-time performance with ProRes scaled linearly with processor count. The Quicktime component for playback was highly optimized for the Mac Pro, and thus could play back roughly twice as many streams in real time on an eight-processor system as on a four-processor system. Linear scalability is the holy grail of parallel computing, and Apple came about as close as humanly possible to achieving it with ProRes and Final Cut 6 ? without making any major parallelization-related changes to Final Cut itself. It was all in that one module.
Similarly, the Smoothcam feature that was a major selling point of Final Cut 6 (it was 6, right?) is implemented as a plug-in. It wasn't necessary for Apple to rip out big chunks of the application to add that feature; they just implemented it as a plug-in and went on with their lives. This had the advantage of leaving the core application basically untouched, as far as the Smoothcam feature was concerned, which meant it was both easier to implement and less likely to introduce regression bugs in the application itself.
Does that mean Final Cut is perfect? Of course not! Even aside from the fact that there's always room for improvement in everything, there are some really obvious opportunities for improvement in Final Cut as it stands right now. The rendering engine could stand to be modularized, like playback and effects are today. If Final Cut wants to be a viable finishing system (which is not necessarily the case, but go with me) then the focus needs to be on ubiquitous real-time performance. Final Cut needs a real-time color corrector, real-time DVE, and at least two layers of real-time compositing. We're a long way from that; right now, Final Cut can't even consistently do real-time dissolves with full-resolution media. Dissolves! That's the simplest thing an editor can do! The focus for the Final Cut engineering team, in my just-some-random-guy opinion, needs to be on eliminating "render" as a thing the operator needs to know about. Will they ever succeed entirely? Of course not; inevitably, somebody's going to decide he wants to use Final Cut as a full-fledged 3D compositing system (sigh) and will try to stack up twelve or sixteen layers on the timeline and be dismayed to see the giant "Are you kidding?" error box pop up. But a reasonable goal should be to make eighty percent of what eighty percent of editors do be real-time.
Will they ever achieve that? No. I really don't think they will. You want to talk about GPU? Okay. When Autodesk ported Smoke to the Mac, they declared unilaterally that the only supported graphics option would be the eighteen hundred dollar QuadroFX board. Smoke won't run at all without that board. The technical reason revolves around backpath performance and drawing rendered frames back off the board and into main memory, but whatever. Point is, if you want a real-time system, you have to pay for it in two ways: first, by giving up the flexibility to just install the software on pretty much any computer you have lying around, and second by handing over lots of pictures of George Washington to get the right gear.
It sucks, but there's a lot that the graphics card in your Mac Pro just isn't useful for when it comes to Final Cut. Could the software take better advantage of graphics cards in general? Sure! OpenCL provides a robust software framework that opens up the possibility of offloading processing tasks to the graphics coprocessor ? or indeed, any other coprocessor, in principle like the Red Rocket board for R3D coprocessing ? and it'd be great if Final Cut took advantage of that. But the unhappy truth is that graphics boards aren't ready yet to be used as general-purpose processing nodes. There are still too many shortcomings ? like the aforementioned backpath performance ? that were never relevant as long as the graphics board's job was to do nothing more than take OpenGL instructions and textures from the computer and turn them into a raster. OpenCL lays the groundwork, but it's still up to the IHVs to do their part.
Snow Leopard, as I mentioned before, marked the public debut of a couple of fundamental core technologies ? GCD and OpenCL ? that have the potential to radically change the way high-performance software is written. But big changes happen slowly. Not this year but possibly next, and almost certainly by mid-2012, we'll see Final Cut Pro 8. Don't be surprised if at that time the software has been enhanced by these underlying core technologies to emphasize real-time performance. It just can't all happen overnight, y'know? And you're certainly not more likely to get it sooner by imploring Apple to discard all the work that's been put into Final Cut