Re: [eclipse-clp-users] Slow OutOfProcessEclipse under Unix/Linux

Hi Martin,

I am not sure what more I can add. Let me try and expand on what I said 
previously:

The OutOfProcessEclipse and the RemoteECLiPSe are both seen (and 
implemented) as remote peers by ECLiPSe. This means that the 
coomunication (peer queues) are implemented via sockets. This
includes the ECLiPSe RPC, which are implemented on top of the peer queues.

When the remote peers were first implemented some years ago (originally 
the remote peer was for Tcl, this was expanded to Java later. I did not 
implement the Java side of the interface), I did some timing 
measurements of sending data via sockets. This was probably done on 
Linux. From memory, the result showed:

1. There is an overhead (delay) in sending any data via sockets. This 
was reasonably substantial, although I can't remember the exact amount, 
but it was probably several tens of milliseconds, say 50ms. I suspect 
this delay is not strongly related to the speed of your processor.
The embdeed interface does not have this delay at all.

2. Transmission of the data is slower (compared to the embedded 
interface (which uses in memory buffers). At a minimum, the data needs 
to be copied from one buffer to another (from the sending to the 
receiving end).

For the ECLiPSe RPC, you are using the queue twice: once for sending the 
goal to ECLiPSe, and then again for sending the results back to the 
remote peer (Java, in your case).

Togehter this suggest that the communication for the remote interface 
would be less efficient than the embedded interface (as stated in the 
documentation), and that you should try to avoid sending small amounts 
of data via the queues very frequently, because of the (relatively) high 
overhead you pay for each communication.  For ECLiPSe RPC, this implies 
that each RPC needs to run for relatively substantial amount of time to 
overcome the overhead of using the socket I/O twice.

The reason for using sockets is of course this gives you much more 
flexibility -- your remote peer can be on a remote machine. However, 
there does seem to be a price to pay for the flexibility.

The amount of computation you seem to perform for each of your ECLiPSe 
RPC seem very small -- less than 10ms it seems. The remote interface is 
not really designed to be efficient in such cases. I am rather surprised 
that you seem to have much less overhead in using the Windows version. I 
don't quite understand this. Note there is no differences in the 
implementation of the RPC on Windows and Linux, and the only difference 
are the system calls to sockets.

So trying to do more in ECLiPSe is the best way round this. You said 
that the algorithm runs slower if it is all implemented in ECLiPSe, when 
compared to Java. How much slower is it? I would expect the difference 
between implementing in Java rather than ECLiPSe to be much smaller than 
the difference between ECLiPSe and C.

Cheers,

Kish

Martin Wegner wrote:
> Hello,
> 
> but not when you have a huge communication...
> Every game stands for one very small communication between java und
> OutOfProcessEclipse.
> And when we play 14000 games in 60 seconds we have 233 communication
> steps every second per core.
> 
> With Windows XP no problem, with Unix/Linux a very big problem :(
> 
> It seems that the RPC under Unix/Linux is slower than in Windows XP...
> 
> Under Windows XP my CPU runs with 100% (70% eclipse.exe and 30% Java).
> Under Linux my CPU runs with 45% (35% eclipse.exe and 10% Java).
> 
> I wrote some emails with Kish but their is no solution until yet :(
> 
> Greetings!
> 
> Martin
> 
> 
> 
> Wit Jakuczun schrieb:
>> 2008/9/13 Martin Wegner <martinator.de_at_...114...>:
>>   
>>> Hello,
>>>
>>> I'm a student and work on a project that uses eclipse prolog with
>>> OutOfProcessEclipse and Java.
>>>
>>> Now I observe that OutOfProcessEclipse is very very slow under Unix/Linux :(
>>>
>>>     
>> I have used OutOfProcessEclipse on Sparc/Solaris and it worked
>> quite efficiently. Overhead on transfering data from Java to ECLiPSe
>> was negligible. Size of data was approximately 50kB.
>> There was no difference in runnig speed (not counting time needed
>> to transfer data) between Windows and Solaris.
>>
>> Best regards
>>   
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> ECLiPSe-CLP-Users mailing list
> ECLiPSe-CLP-Users_at_lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/eclipse-clp-users


-- 
This e-mail may contain confidential and privileged material for the
sole use of the intended recipient. Any review, use, distribution or
disclosure by others is strictly prohibited. If you are not the intended
recipient (or authorized to receive for the recipient), please contact
the sender by reply e-mail and delete all copies of this message.
Cisco Systems Limited (Company Number: 02558939), is registered in
England and Wales with its registered office at 1 Callaghan Square,
Cardiff, South Glamorgan CF10 5BT.