Szczerze sam jestem ciekaw chociaż nie posiadam takiego procesora =) Na jakimś forum czytałem, że FL kiepsko sobie radzi z obsługą wielu procesorów, ale traktuję tą informację jak zwykłą plotkę. Zaraz poszukam na stronie IL dokładniejszego info.
EDIT:
Owszem jest wsparcie, ale tak jak myślałem - kupując quada nie będziemy 4x szybsi =) Korzystanie z kilku rdzeni jest dość specyficzne. Wiadomo, że single 1,6 ghz zapchamy bez większego wysiłku, a dual/quad 1,6 ghz już trudniej. Kilka rdzeni ma głównie na celu pozwolić na uruchamianie kilku aplikacji jednocześnie - robienie wielu rzeczy w tym samym czasie, ale jeżeli chodzi o skupianie całej mocy na jednym zadaniu to raczej nie. Wiadomo, że struktura nowych procesorów Intela jest niesamowicie wydajna. Z resztą - wklejam treść posta z forum IL. Tam jest wszystko dokładnie wytłumaczone.
=========================================
Ok a multicore CPU is basically, for the software, several CPU's, that can process in parallel. What can be processed in parallel in Windows? Threads. While an app has means to tie a thread to a particular core, it generally doesn't make sense to do that. Windows processes threads in timeslices. If there's a timeslice to process & a CPU is available, it will map it to that CPU. Thus an app isn't "running on a core", it can have some timeslices processed by a CPU & other timeslices by another.
Now multithreaded processing & audio:
-4 cores will NEVER be 4x faster, not even in theory, that's just marketing. Even in an ideal case with even CPU load, with the overhead of synchronization it would never result in 4x performances. In practice, it I don't think many of your apps will benefit from this. But it's marketing & CPU speeds weren't raising much anymore, so this was a last attempt. Processes (apps), though, are usually perfectly independent, so a multicore is great when running several apps at the same time.
So multicores aren't a sign of success, it's a sign of failure (failure to keep raising CPU speeds), masked as a success by marketing. Ideally, you would have gotten 4x faster CPU's, not 4 same of them tied together. But of course a dirty solution is better than no solution.
Not only multithreaded prorgamming is much harder, it's also much riskier, a multithreaded app is likely to have more bugs, and thread-related ones are of a much higher level to fix (because less easy to replicate, and because usually involving a complex net of synchronizers). But anyway, it doesn't look like it's going back.
-angain, an app accesses threads, not cores. You can run 20 threads on a single core or 1 thread on a quad core. Windows manages all this.
-ANY audio sequencer has at least 2 threads, one for the GUI, and a higher-priority one for the audio, so that the audio isn't broken by GUI. This already makes any audio sequencer benefit from a dual core CPU, on which you should normally have a smooth GUI even on high mixer cpu usage.
-multithreaded plugin processing in a sequencer depends on:
1. the ability of the plugins themselves of being thread-safe & multithreadable. Our own plugins are all thread-safe, but not many of them are multithreadable for now. A Sytrus will not process at the same time as another Sytrus, and this is in ANY sequencer. Sytrus isn't thread-safe for now & had to be protected. Over time we will make our own CPU-intensive plugins multithreadable.
If the plugin isn't thread-safe, it will crash or give wrong results, it's that simple, and that's why there's an option to disable this, per-plugin.
2. the multithreading method. Lots of variants here, you can run a thread per-plugin, or a the same amount of threads as there are cores, there are pro & con's for each method. FL will use up to 16 threads for all plugins, whatever the # of cores. This ensures that a plugin in a locked state won't slow down the whole chain, and it ensures a smoother CPU spread, but that means some more overhead.
3. how those threads are synchronized. Multithreaded processing will involve a scheduling that's not very friendly with a low audio latency. Some sequencer may look like it works more smoothly in them, but those are mixing ahead of the audio bufferswitch (I won't get into the details), thus usually result in 2x the latency that you have chosen.
4. this is probably FL-specific, what is actually multithreadable. In FL, it's generators only, not effects. Of course FL has threads for several other things, like MIDI handling, timers, recording to disk, etc.
5. YOUR PROJECT. It would be really naive to expect a quad core to process plugins 4x faster. This would be in a rare case where all plugins would run in parallel, where all plugins would be multithreadable. For FL's generators, that means right now only a few of our plugins. Again, no need to test with Sytrus, since it's not multithreadable yet, you won't see any benefit. Multi-output plugins will also be less efficient.
And even in the best case where all your plugins are multithreadable, there's still the scheduling itself (those who have a single core can notice that switching multithreaded processing on, already eats more CPU), the automation, mixer, etc.
About effects: they're not multithreadable in FL. But this is the worst case for multithreading, as there's often a dependency. In ANY sequencer's mixer, you would never get 4x more efficiency our of 4 cores, because of that dependency. You obviously can't process an effect if it's fed by another effect, and that output isn't ready yet. So all of the effects in a mixer slot can't be processed in parallel, it's the whole mixer slot that can. Those mixer slots feed others in the worst case, or in the best case, just the master. If you have 2 effects that eat 20% of your CPU in slot 1, and an effect that eats 5% CPU in slot 2, and one in the master that eats 15%, you will NOT get (20%+5%+15%)/4 on a quad core. You will get, in the very best case, 20%+15%, because the slot(s) that eats 5% will be processed at the same time as the 20% one. Then you have to take into account the usual track routing & sends.
So with ideal, non-realistic projects you can see huge benefits, but you have to test real benefits in all sequencers.
In FL, a project with only non-multithreadable native plugins, and lots of effects, will give zero benefit. A project with lots of threadable VSTi's & no effects will give huge benefits. Typical projects will be somewhere in-between.
So please stop looking at your cores in your task manager like nerds.
=========================================
