delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2004/08/05/07:24:05

Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Message-ID: <411218B2.3080207@x-ray.at>
Date: Thu, 05 Aug 2004 13:23:30 +0200
From: Reini Urban <rurban AT x-ray DOT at>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-AT; rv:1.7) Gecko/20040616
MIME-Version: 1.0
To: "Clarke, Trevor" <tclarke AT ball DOT com>
CC: cygwin AT cygwin DOT com
Subject: Re: question about shared memory in the cygwin daemon
References: <A5F4BEF689E6FA47BC56396D0B9F15057F15D7 AT daytonmsg2k DOT aero DOT ball DOT com>
In-Reply-To: <A5F4BEF689E6FA47BC56396D0B9F15057F15D7@daytonmsg2k.aero.ball.com>
X-IsSubscribed: yes

Clarke, Trevor schrieb:
> We currently run on 32bit windows and 32/64but solaris with near future
> plans to run on 64bit windows. The product is for a specific client so
> we can assume 4gb or more of physical ram.
> 
> As for Matlab, the problem is that the library routines for embedding
> matlab spawn a separate process and use IPC to talk to it (COM under
> windows I believe) so data sent is copied to another address space.

COM!
Then the matlab COM server must be run inproc to be able share memory 
from the same address space. COM marshalling detects that and does 
nothing. Otherwise you'll loose. Looks at the various COM books which 
exist online.
   "Inside OLE 2" by Craig Brockschmidt is a good tip:
   http://msdn.microsoft.com/library/books/inole/S10AA.HTM

This has nothing to do with cygwin, normal microsoft windows API calls 
will succeed.

> Again, we can assume sufficient RAM for a data set and even if a page is
> swapped out to disk, it should be data that's not actively processing so
> the impact on performance should be less than processing directly on
> disk.
> ------------------------------
> Trevor R.H. Clarke
> tclarke AT ball DOT com
> Ball Aerospace & Technologies Corp
> 
> -----Original Message-----
> From: Dave Korn [mailto:dk AT artimi DOT com] 
> Sent: Wednesday, August 04, 2004 1:37 PM
> To: cygwin AT cygwin DOT com
> Subject: RE: question about shared memory in the cygwin daemon
> 
> 
>>-----Original Message-----
>>From: cygwin-owner On Behalf Of Clarke, Trevor
>>Sent: 04 August 2004 17:54
> 
> 
>>I'm currently developing image processing software which will 
>>use matlab
>>as a "plugin" for interactive processing. The problem is, matlab, when
>>called from another program, spawns a separate matlab engine process.
>>The data we are working with can get very large (4gb+) so we 
>>can't pass
>>copies of it around. We are looking at using cygwin's shared memory
>>functionality to get around this on windows (NT derivatives only).
> 
> 
>   Your data won't even fit into a 32-bit address space, so I don't think
> shared memory is going to help you.
> 
>   Even if you're using an x86-64 platform, you have to bear in mind that
> you've got a virtual memory system there.  If your data set is 4Gb, and
> your
> system RAM is < 4Gb, then even mapping it into shared memory between
> processes will involve it going out to disk and back when the pagefile
> starts swapping.
> 
>   Is there not a library version of matlab you can link to your
> application
> and call into from the same process space?
> 
> 
>     cheers, 
>       DaveK
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019