| To: | "REALbasic NUG" <realbasic-nug at lists dot realsoftware dot com> |
|---|---|
| Subject: | Re: Dealing with multi-processor or multi-core |
| From: | "Peter K. Stys" <pkstys at gmail dot com> |
| Date: | Fri, 30 May 2008 14:02:56 -0600 |
| 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: | <77124270805301112ja025ec1i5295f790cf52d33b at mail dot gmail dot com> <BAY107-DAV13E1BCBA0B8DD7A3965E3D93BE0 at phx dot gbl> |
On Fri, May 30, 2008 at 1:31 PM, Daniel Stenning <d0stenning at msn dot com> wrote: > What might help is some facility in the RB language to support "shared > memory". This requires semaphores etc but is faster when we need to share > big amounts of data amongst several processes ( or helper apps ). Passing > huge chunks of data via IPC is slow. I'd second this: if multiple cores/threads/processes are needed, it's usually because you need to operate on a large amount of data in parallel. Sending it via IPC or Notification may take as long as crunching it by a single thread, defeating the multicore exercise. -- --------------------------------------------- Peter K. Stys, MD Dept. of Clinical Neurosciences Hotchkiss Brain Institute University of Calgary tel (403) 210-8646 --------------------------------------------- _______________________________________________ Unsubscribe or switch delivery mode: <http://www.realsoftware.com/support/listmanager/> Search the archives: <http://support.realsoftware.com/listarchives/lists.html> |
| Previous by Date: | Re: Dealing with multi-processor or multi-core, Daniel Stenning |
|---|---|
| Next by Date: | Re: Dealing with multi-processor or multi-core (shared memory semi solution), Tom Benson |
| Previous by Thread: | Re: Dealing with multi-processor or multi-core, Daniel Stenning |
| Next by Thread: | Re: Dealing with multi-processor or multi-core (shared memory semi solution), Tom Benson |
| Indexes: | [Date] [Thread] [Top] [All Lists] |