Services & Resources / Wolfram Forums
-----
 /
MathGroup Archive
1998
*January
*February
*March
*April
*May
*June
*July
*August
*September
*October
*November
*December
*Archive Index
*Ask about this page
*Print this page
*Give us feedback
*Sign up for the Wolfram Insider

MathGroup Archive 1998

[Date Index] [Thread Index] [Author Index]

Search the Archive

Re: Which Communications to Use for MathLink on NT?


  • To: mathgroup@smc.vnet.net
  • Subject: [mg11956] Re: Which Communications to Use for MathLink on NT?
  • From: kevinl@wolfram.com (Kevin Leuthold)
  • Date: Fri, 10 Apr 1998 01:03:45 -0400
  • Organization: Wolfram Research, Inc.
  • References: <6ghikn$ler@smc.vnet.net>

Hello,

There is a bug in the FileMap MathLink protocol for Mathematica 3.0 that
affects the speed of communication under Windows NT.  (This bug does
not affect Windows 95).  This is most likely the reason for the
slowdown you are experiencing.

On Windows 95 and Windows NT, the two protocols that can be used are
FileMap (mlmap32.mlp) and TCP (mltcp32.mlp).  FileMap is the default
protocol.  It uses file-mapping objects as a method of communicating. 
TCP is generally  used for communication between processes on different
machines.

This bug will be fixed in the next major release, and tests we've run 
indicate that MathLink communication will be dramatically faster using 
the FileMap protocol under Windows NT - as much as 50 to 70 times as 
fast for some applications of MathLink.

Unfortunately, we do not know of any workarounds for Mathematica 3.0
users.

Kevin Leuthold
MathLink Group
Wolfram Research


Adalbert Hanszen <hsse@amath01.amath.zeiss.de> writes:

>Hi, mathgroup

>in [mg11314] I asked about the slowdown of MathLink on NT machines.
>There was one RE-posting on this, also I got another response by direct
>email. 

>Both also encountered this slowdown. One told me, it is almost directly
>proportional to the number of MathLink calls and almost independent of
>the amount of data transferred in the calls.

>To overcome it, both suggested to buffer calls, i.e. write another
>interface for the function to be called many times, collect all the
>arguments and then call the "buffered" function only a few times
>returning multiple results over one MathLink call.

>This however would screw up the structure of my programming quite a bit.
>It certainly would help, as first experiments show.

>Now I asked an NT expert, because I still can not believe, that the idle
>process eats up that much processor power (much more than 90%!) even if
>there is lot of work to be done. The expert told me, if TCPIP  is the
>underlying data transport mechanism, he would not wonder about  this
>slowdown. TCPIP is very fine to connect to other computers, but as a
>means of communication within the same computer... If I would use 
>named pipes instead, he expected much increase. According to him, TCPIP
>always  includes "waiting for the network being ready", even if there 
>is no physical network and if it is all in the same computer. He was
>not  amazed, that the Idle process takes over many times, although one
>of the two (frontend or the mathlinked program) is always ready.
>According to him, it is technically possible, to exchange data between
>Programs on NT without the Idle process coming in between (if there is
>no disk- activity, only other Programs or NT itself might come in
>between,  according to priority).

>With this information, I looked up the Mathematica-bible. On pp631 and
>655 I found, that "MathLink can use any interprogram communications
>mechanism, that exists on your computer system". Well, HOW can I  tell
>* which communications mechanism my system takes by default, * which
>other communications mechanism I might use instead, and how can I
>actually direct it to use NamedPipes. In Mathematica 2.2.3, if I
>remember right, there was a dialog box where one might select "LOCAL"
>protocol. Where has this choice gone now? - even if the LOCAL protocol
>does not exist any longer?

>One other thing, my NT expert suggested to me to think about
>programmati- cally increasing the priority of the MathLink process
>(after it has gained control) in order to prevent it to be pre-empted
>too often and to return its priority to the normal state, before it
>goes to sleep. Would this be feasible?

>Thanks in advance,

>Dipl.-Math. Adalbert Hanszen <hsse@amath01.amath.zeiss.de>




  • Prev by Date: Re: AutoEvaluateOnOpen
  • Next by Date: Re: Is it a BUG?
  • Prev by thread: Which Communications to Use for MathLink on NT?
  • Next by thread: Beginner ReadList