static library to sockets on localhost

[call_me_anything]

Hi,

We had a library linked dynamically in our 32 bit mode.
Now due to capacity issues, we are planning to move on to 64 bit but
the library is still 32 bit and
we cannot make it 64 bit without a mammoth effort.
So we decided to use IPC via sockets such that the library calls are
run on a 32 bit machine while
our application runs on a 64 bit machine.
But that is slowing down the things by a factor of say 100.
Is this expected ?

I am using Tcl sockets for this purpose and right now, both the
processes are running on the same machine.
Our application built in 32 bit mode to test the IPC mechanism.

 

[Gianni Mariani]

Hi,

We had a library linked dynamically in our 32 bit mode.
Now due to capacity issues, we are planning to move on to 64 bit but
the library is still 32 bit and
we cannot make it 64 bit without a mammoth effort.
So we decided to use IPC via sockets such that the library calls are
run on a 32 bit machine while
our application runs on a 64 bit machine.
But that is slowing down the things by a factor of say 100.
Is this expected ?

Well, yes. It depends on how much you're calling and waiting for your
32 bit library.

I am using Tcl sockets for this purpose and right now, both the
processes are running on the same machine.
Our application built in 32 bit mode to test the IPC mechanism.

Sounds like it's time to re-write your 32 bit DLL, or at least the bits
you use.

 

[=?ISO-8859-1?Q?Erik_Wikstr=F6m?=]

Hi,

We had a library linked dynamically in our 32 bit mode.
Now due to capacity issues, we are planning to move on to 64 bit but
the library is still 32 bit and
we cannot make it 64 bit without a mammoth effort.
So we decided to use IPC via sockets such that the library calls are
run on a 32 bit machine while
our application runs on a 64 bit machine.
But that is slowing down the things by a factor of say 100.
Is this expected ?

I am using Tcl sockets for this purpose and right now, both the
processes are running on the same machine.
Our application built in 32 bit mode to test the IPC mechanism.

For future questions like this please use a group discussing your
platform or the libraries you are using, the question is off topic here.
The fact that the code was written in C++ (it was right?) does not make
the question topical.

As to your problem, what you are doing now seems to be RPC (Remote
Procedure Call) not IPC (Inter-process communication) so my suggestion
is that you try to use IPC instead. Wrapp the library in a small
application which is then run in 32-bit mode on the 64 bit computer.
Then the 64-bit application and the library can communicate via IPC
messages. Depending on your usage you might not notice any slowdown at all.

 

[James Kanze]

We had a library linked dynamically in our 32 bit mode.
Now due to capacity issues, we are planning to move on to 64 bit but
the library is still 32 bit and
we cannot make it 64 bit without a mammoth effort.

Isn't it sufficient to just recompile it?

So we decided to use IPC via sockets such that the library calls are
run on a 32 bit machine while
our application runs on a 64 bit machine.
But that is slowing down the things by a factor of say 100.
Is this expected ?

It might be. It depends on a lot of things. Most of which are
system dependent: under Unix, for example, you should ensure
that you are using Unix domain sockets, and not TCP. You'd best
ask in a group specific to your OS.