Kish Shen wrote: > 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 > > I ran some tests with sockets, trying to reproduce the tests I did previous. I think the results I remember was for socket connections between different machines, rather than between processes on the same machine. However, on the Linux machine I ran the test on, it seems that there is a performance problem when the data sent via the socket is between 4K and 40K in size. I assume this is some buffer issue. I don't see this on my XP laptop. Do you think your RPC goals may be in that size range? [You probably need some largish data structure in your goal to reach that sort of size] Cheers, Kish -- 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.Received on Wed Sep 17 2008 - 10:49:21 CEST
This archive was generated by hypermail 2.3.0 : Tue Apr 16 2024 - 09:13:20 CEST