realbasic-nug
[Top] [All Lists]

Re: Dealing with multi-processor or multi-core

To: REALbasic NUG <realbasic-nug at lists dot realsoftware dot com>
Subject: Re: Dealing with multi-processor or multi-core
From: Giovanni <rbml at alphaview dot com>
Date: Fri, 30 May 2008 10:19:03 -0700
Authentication-results: mx.google.com; spf=pass (google.com: domain of realbasic-nug-bounces at lists dot realsoftware dot com designates 66.116.103.65 as permitted sender) smtp dot mail=realbasic-nug-bounces at lists dot realsoftware dot com
Delivered-to: listarchive at realsoftware dot com
Delivered-to: realbasic-nug at lists dot realsoftware dot com
References: <p06240802c4657bd7c318 at [62 dot 161 dot 36 dot 122]> <41B4C50C-AB85-4975-B2AE-C6A4DD49D787 at inspiringapps dot com> <p06240804c465e06353d5 at [62 dot 161 dot 36 dot 122]> <D01600E9-BB0D-49DF-8990-65E4B1F93D14 at tolisgroup dot com>
But even on a single processor, you would see a tremendous gain if the 
required process is doing stuff like a downloader helper app. The helper 
app would continue to download while the master app would remain highly 
responsive. Would that be right?

Giovanni
----------------------



Tim Jones wrote:
> On May 30, 2008, at 9:54 AM, Jean-Luc Arnaud wrote:
>
>   
>> Thanks for information, Joe.
>>
>> Could you say a little bit more on helper app, or give us links to  
>> articles ?
>>
>> Perharps, I'm doing so without knowing it. My main app runs as many  
>> apps as necessary for achieving parallel tasks. Of course, there is  
>> communication flow between main app and daughters apps.
>>     
>
> That's a perfect description.  Here's an example of one of my projects:
>
> We have a pair of tools that run from the command line.  One talks to  
> the server app for our system while the other actually performs data I/ 
> O for the movement of data between the client system and the server.   
> We can be managing multiple operations from within a single management  
> console and each of the shelled copies of the communication tool will  
> be running as a separate process.  If we are running on a multi-proc  
> system, there is a good chance that the executive will run each  
> instance on a different processor/core.  It's just one of the things  
> that the Unix paradigm provides without the headaches discussed  
> concerning managing multiple preemptive threads.
>
> However, I do take things one step further and execute each of the  
> streams above in its own RB cooperative thread to ensure the UI stays  
> responsive.
>
>   
>> Should I benefit of multitasking, doing that ? It seems like I don't  
>> (perharps badly coded !!).
>>     
>
> I suspect that you are if you have a multi-proc system.  Of course,  
> there's no real win outside of more elegant process management if  
> you're on a single proc system...
>
> Tim
> _______________________________________________
> Unsubscribe or switch delivery mode:
> <http://www.realsoftware.com/support/listmanager/>
>
> Search the archives:
> <http://support.realsoftware.com/listarchives/lists.html>
>   
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>


<Prev in Thread] Current Thread [Next in Thread>