|
| quote: | Originally posted by DJ Robby Rox
I think you might have it a bit backwards with that last sentence about programmers exhausting extra effort to criple their programs. Programming software to support 2 cores I was told my a tech buff is relatively difficult enough, but writing the code to support 4 or even 6 is a lot harder.
|
Yes and no. To clarify on this point, when you talk about multiple cores, you are really referring to how many threads can run concurrently at any given moment.
Single core processors can actually only operate on one work unit at a time, but because of lightning fast task switching and scheduling, it can appear to perform many actions at the same time, even though the processor is only doing one thing at a time.
The ability to support multiple cores really boils down to the specific type of processing task you are trying to accomplish and how much that task lends itself to being parallelized in the first place, regardless of how many cores (or threads) you are dealing with.
So in one sense, yes, you are correct in the statement that coding for 2 cores is difficult enough, and coding for 4 and 6 is even more difficult, but only because the process of synchronization has always been done manually. Obviously its easier to synchronize two threads rather than 4 or 6. Anyone who has done any type of multi-threaded software development can attest to the giant PITA it can be (especially debugging).
However, updates and newer languages are now providing built in mechanisms to make this process of synchronization much, much easier. For example, .NET 4.0 includes many new libraries for dealing with parallel tasks, and even provides several thread safe collection types (a notoriously difficult object type when dealing with parallelization).
As this relates for DAW software, the ability to run on multiple cores (threads) boils down to the approach used to take advantage of a multi-core setup. In most DAW packages (Logic in particular), one technique is to assign each audio/instrument channel to a single core (thread). While this creates the advantage of making the application more multi-core aware, the disadvantage to this approach is that if you overload a channel with 6 or 7 plugins, then all that processing on that channel is still assigned to a single core. You can actually gain a performance advantage by routing that channel to a AUX bus and moving 3 or 4 of those plugins to that bus. This way each channel only has 3 or 4 plugins on it at one time and the processing of those channels can be assigned to separate cores. Is this true "multi-core" support or is this just what one might call "multi-core compliant"? Ask 10 different developers and you'll get 10 different answers.
There are other techniques use in DAW software packages that also take advantage of multi core setups, but describing those is well beyond the scope of this forum.
I believe FL is written in Python, which is a another relative newcomer to the multi-core game, at least as far as providing developers an easy way to make their applications take advantage of multi-core processors. Since the original design of FL likely did not take in to account multi-core setups (and why would they have back then), design decisions were probably made that makes it a bit difficult to just "add" multi-core support without major re-design. So the next best thing is to parallelize what you can and slowly redesign key features over a period of time to make the application more and more capable of taking "full" advantage of multi-core processors. Logic has gone through this transformation recently starting with Logic 8 and really only now at version 9.1.3 has it seemed to finally come to fully support and fully utilize multi-core processors. Logic 8 was notorious for making uneven use of multi-core processors (1 would be at 100%, while the others might only be at 20 or 20%).
Every major software package has had to go through this process, the only difference is that some companies have more money and people to throw at the problem, so they get it done faster. FL will get there eventually, they just might not have as many resources to throw at the problem as someone like, say, Apple.
Last edited by Eric J on Nov-28-2010 at 06:21
|