I hope that after Universal Binary gets implemented, that Mars (or someone else) can sit down and figure out portions of the Framework which can be Multiple-Processor safe. I seem to remember hearing that "For Each" is a good possible candidate because of the out-of- order processing. At the rate that Intel and AMD is going, everyone is going to have a dual-core system (or better) in a couple of years. And given a choice, I would much rather have limited/ restrictive MP support over Cocoa, Swordfish or any other major feature (except UB). Heck, compiling Applications with MP- enhancements would make a very attractive Pro-Only feature to REALbasic.
Not to toot my own plugin/class, but you can already take advantage of MP with PreemptiveThreadTD. http://www.taylor-design.com/toolkits/index.html It's not automatic. You have to decide what tasks can be split up in your application, and how to split them up, and put them into preemptive threads. And not everything can be done safely from a preemptive thread. But if you have an application that does a lot of work across existing RB threads, it's a good way to get that work spread out among cores. For example, if you had a huge array to process and two cores, you might split it in half and spawn two preemptive threads to do the processing. Note that the OS might not decide to schedule the threads on separate cores if a lot is going on in the system. In version 2 it's up to the OS, though I believe I can add code on both OSes to allow the developer to force the issue. FWIW, I'm not sure how much can be gained by RS trying to introduce "automatic" MP in the language vs. the problems that could be created. I would rather see a definitive list of what framework classes and methods are safe to use in a preemptive thread, assuming potential synchronization issues are handled by the programmer. The developer is in a much better position to understand how work within a particular application can take advantage of multiple cores. Automatically trying to schedule For...Each across two cores might take longer on a short array than sticking with one (there's overhead for launching and managing threads), cause issues with code that touches memory "outside" of the For...Each construct, or not efficiently split up the elements to process (i.e. 0-9 take 100x longer than 10-19; the programmer might know this and be able to manually split up the work more efficiently). Daniel L. Taylor Taylor Design Computer Consulting & Software Development [EMAIL PROTECTED] www.taylor-design.com _______________________________________________ Unsubscribe or switch delivery mode: <http://www.realsoftware.com/support/listmanager/> Search the archives of this list here: <http://support.realsoftware.com/listarchives/lists.html>
