Win32 x64?

I know its planned, but is there anything more specific as far as 751 or 76 inclusion? I'm pondering running multiple server images and shared perm saving seems to be the key in that scenario once over a certain number of concurrent instances.
Cheers!

-Boris
(Sent from a BlackBerry)

Heh, of course 32 and 64 in the same subject is a slight oxymoron, but such is the mechanical memory, hard not to type that...

Cheers!

-Boris
(Sent from a BlackBerry)

----- Original Message -----
From: Boris Popov
To: '[hidden email]' <[hidden email]>
Sent: Tue May 08 20:50:59 2007
Subject: Win32 x64?

I know its planned, but is there anything more specific as far as 751 or 76 inclusion? I'm pondering running multiple server images and shared perm saving seems to be the key in that scenario once over a certain number of concurrent instances.
Cheers!

-Boris
(Sent from a BlackBerry)

---

From: Boris Popov [mailto:[hidden email]]
Sent: May 8, 2007 8:53 PM
To: [hidden email]
Subject: Re: Win32 x64?

Heh, of course 32 and 64 in the same subject is a slight oxymoron, but such is the mechanical memory, hard not to type that...

Cheers!

-Boris
(Sent from a BlackBerry)

----- Original Message -----
From: Boris Popov
To: '[hidden email]' <[hidden email]>
Sent: Tue May 08 20:50:59 2007
Subject: Win32 x64?

I know its planned, but is there anything more specific as far as 751 or 76 inclusion? I'm pondering running multiple server images and shared perm saving seems to be the key in that scenario once over a certain number of concurrent instances.
Cheers!

-Boris
(Sent from a BlackBerry)

On May 9, 2007, at 4:52 PM, Joerg Beekmann wrote:

> What would be interesting is a bit of a chart indicating under  
> which conditions one would actually see a saving by going to 64 bit  
> and using shared perm space. In may scenarios the "unshared"  
> portion of the the 64 bit image could be larger than the entire 32  
> bit image. Not to  mention that it is generally slower due to  
> memory bandwidth limits.

Is that last bit true?
I would expect a 64 bit machine to have twice as wide a memory bus as  
a 32 bit one. But I haven't looked into hardware architecture for  
ages, so I might be wrong.


R
-

From what I heard, the x64 VM is only 5-10% slower, which is much better
than some other applications out there ;)

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5
http://tinyurl.com/r7uw4

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.

On 5/9/07, Boris Popov <[hidden email]> wrote:The point is that no matter how wide the memory bus is a 32-bit application can load twice as many spatially co-located pointers in the same amount of time as a 64-bit one simply because 32-bit pointers are half as wide as 64-bit ones.  This doesn't apply to binary data such as doubles or bitmaps.  So one would expect symbolic applications that don't fit in cache but do fit within the 32-bit address space to be faster than the 64-bit version and one would expect numeric applications to be the same or fater.  That's broadly what one sees.  The slow-down is only 15% for the symbolic computation the standard benchmarks do because the 64-bit implementation uses various tricks to speed things up:

- the 64-bit object header is 16 bytes compared to the 12 bytes of the 32-bit one, only a 33% increase

- the 64-bit VM uses the header's alignment modulo 8 bytes to distinguish perm space objects from old space objects, making part of the store check smaller and faster

- the 64-bit object header includes the number of named inst vars so that at: and at:put: don't have to fetch the class to find them out, making at: and at:put: faster than the 32-bit vm.

- the 64-bit object header stores a class index which fits in 20 bits and is used as the tag in all inline caches instead of the 32-bit's direct class reference.  The 64-bit vm maintains a sparse table mapping class indices to classes.  So in-line caches are basically the same in the two systems (loading 64-bit literals (inline class tags) can be extremely expensive, e.g. on SPARC  one needs 6 32-bit instructions to load an arbitrary 64-bit literal)

- the 64-bit vm supports immediate doubles lying in the float range, making typical double arithmetic a lot faster than the 32-bit VMs boxed floating point.

All of these conspire to make the slow-down less than expected.  Very roughly about 40% of computation is binary which shouldn't change between the two, so you'd expect about a 60% slowdown.  With tricks this becomes around 15% to 20% depending on platform.  And this is only for applications that fit in ram.

[hidden email] wrote:
> Hello,
>  
> My application needs to access an unused port number for a
> socket-based implementation.
> IPSocketAddress>>allAboutPortNumbersAndNames states that I can let the
> system assign a port number for a socket using
> IPSocketAddress>>anyPort. But anyPort always returns a 0. I expected
> this to give me an unused post number between firstUnreservedPort and
> maxPort.
No, the assignment of a port happens *later* when you actually start a
server.
Passing in a zero port number only signals to the system that it can use
any free port number.


If you look at #allAboutPortNumbersAndNames again you'll see that it
states that ordering quite clearly:

        2) Let the system assign one for you (each time you start a
server) by fire-ing up a
        server which creates a socket using port:
            IPSocketAddress anyPort
        then do a getName on that socket, print the port number and
supply it to the client
        when you start it up.




listener := SocketAccessor newTCPserverAtPort: 0.
port := listener getName port.
Transcript cr; show: 'Listening on port '; print: port.
listener close




Success!

R
-

Thank you for the reply. My situation is a little weird. We have a
one-way communication from client to server; the client (smalltalk) has
to find a free port, and ask the server (Qt/C++) to listen on that port.
The server does not communicate anything back to the client. So I do not
have the luxury of starting the server specifying port as zero and then
figuring out the port number on which it actually started. This is the
source of my confusion. Any way out here?

Thanks again
Venkat

-----Original Message-----
From: Reinout Heeck [mailto:[hidden email]]
Sent: Thursday, May 10, 2007 12:07 PM
To: [hidden email]
Subject: Re: IPSocketAddress question


[hidden email] wrote:
> Hello,
>  
> My application needs to access an unused port number for a
> socket-based implementation.
> IPSocketAddress>>allAboutPortNumbersAndNames states that I can let the

> system assign a port number for a socket using
> IPSocketAddress>>anyPort. But anyPort always returns a 0. I expected
> this to give me an unused post number between firstUnreservedPort and
> maxPort.
No, the assignment of a port happens *later* when you actually start a
server.
Passing in a zero port number only signals to the system that it can use

any free port number.


If you look at #allAboutPortNumbersAndNames again you'll see that it
states that ordering quite clearly:

        2) Let the system assign one for you (each time you start a
server) by fire-ing up a
        server which creates a socket using port:
            IPSocketAddress anyPort
        then do a getName on that socket, print the port number and
supply it to the client
        when you start it up.




listener := SocketAccessor newTCPserverAtPort: 0.
port := listener getName port.
Transcript cr; show: 'Listening on port '; print: port.
listener close




Success!

R
-

[hidden email] wrote:
> Thank you for the reply. My situation is a little weird. We have a
> one-way communication from client to server; the client (smalltalk) has
> to find a free port, and ask the server (Qt/C++) to listen on that port.
> The server does not communicate anything back to the client. So I do not
> have the luxury of starting the server specifying port as zero and then
> figuring out the port number on which it actually started. This is the
> source of my confusion. Any way out here?
>  
Eh? This more than just a 'little' weird.
Is this a publicly documented API you are using so we can have a look at it?

As far as I know there are no functions to ask the OS which ports are free.

Trying to open a port yourself to see if it is free, then closing it and
and telling the server to use that port will probably not work either,
the IP stack in the OS will probably reserve the just used port number
for a minute or two after closing it so the server cannot use it during
that timespan. Such a strategy would have race conditions anyway, any
other application could grab the port before the server has a chance to
use it...

The API you describe would make more sense if we are talking about a
'well known' port number: client and server always use the same port
number so it doesn't need to be communicated back to the client....



Confused,

Reinout
--------

Reinout,

Well I agree. It sure does not make sense for such an OS feature to
exist; just 64K calls and if the OS were to reserve them all, we are out
of ports already. Seems like our communication loop is badly setup, and
will need to be changed as I nowrealize.
No, this is not a publicly documented API, something we are dicussing
currently for an internal program. It's clear to me that the server (C++
in our case) would have to start on an available port and let the client
know which port to send the commands on. We can not use a "well known
port" scheme here as there can be multiple pairs of server-clients
independent of one another.

Thank you very much for your time

Venkat

-----Original Message-----
From: Reinout Heeck [mailto:[hidden email]]
Sent: Thursday, May 10, 2007 3:16 PM
To: [hidden email]
Subject: Re: IPSocketAddress question


[hidden email] wrote:
> Thank you for the reply. My situation is a little weird. We have a
> one-way communication from client to server; the client (smalltalk)
has
> to find a free port, and ask the server (Qt/C++) to listen on that
port.
> The server does not communicate anything back to the client. So I do
not
> have the luxury of starting the server specifying port as zero and
then
> figuring out the port number on which it actually started. This is the
> source of my confusion. Any way out here?
>  
Eh? This more than just a 'little' weird.
Is this a publicly documented API you are using so we can have a look at
it?

As far as I know there are no functions to ask the OS which ports are
free.

Trying to open a port yourself to see if it is free, then closing it and

and telling the server to use that port will probably not work either,
the IP stack in the OS will probably reserve the just used port number
for a minute or two after closing it so the server cannot use it during
that timespan. Such a strategy would have race conditions anyway, any
other application could grab the port before the server has a chance to
use it...

The API you describe would make more sense if we are talking about a
'well known' port number: client and server always use the same port
number so it doesn't need to be communicated back to the client....



Confused,

Reinout
--------

On 10/05/07, [hidden email] <[hidden email]> wrote:
> We can not use a "well known
> port" scheme here as there can be multiple pairs of server-clients
> independent of one another.

Could you have one server running on a known port on a known server
and use that as a "name server" type thing such that other servers
starting up on arbitrary available ports could register themselves so
the clients could then find them?

This is not a million miles from the kind of thing a CORBA name server works.

--
Make the most of your skills - with OpenSkills
http://www.openskills.org/

[hidden email] wrote:
You may want to have a look at the venerable FTP protocol for inspiration.

FTP has a command channel and for several commands (GET,PUT)  it will
implicitly create a data channel (a new TCP connection) reporting back
to the client on which port number this connection will appear.
 I nice twist is that the protocol allows for the server (the listening
socket) to be set up on either side of the connection (read up on
'passive mode', the PASV command), this helps with firewall traversal.



HTH,

Reinout
-------

Bruce,

Yes, that could be a solution. But I will have to consult  whether we
want to do that, as the server is built into a larger application, not
an independent entity. So it should ideally start only if there is a
connectivity needed.

Thanks!
Venkat

-----Original Message-----
From: Bruce Badger [mailto:[hidden email]]
Sent: Thursday, May 10, 2007 3:52 PM
To: Venkatraj, M
Cc: [hidden email]
Subject: Re: IPSocketAddress question


On 10/05/07, [hidden email] <[hidden email]>
wrote:
> We can not use a "well known
> port" scheme here as there can be multiple pairs of server-clients
> independent of one another.

Could you have one server running on a known port on a known server
and use that as a "name server" type thing such that other servers
starting up on arbitrary available ports could register themselves so
the clients could then find them?

This is not a million miles from the kind of thing a CORBA name server
works.

--
Make the most of your skills - with OpenSkills
http://www.openskills.org/

The more I think about this, I tend to think that I should stick to the
first option that allAboutPortNumbersAndNames suggests. i.e. random
number between firstUnreservedPort and maxPort; at least for my current
application. I am back to square one, but at least more convinced about
why I am here!

Thank you very much! It's been great learning.

Venkat

-----Original Message-----
From: Reinout Heeck [mailto:[hidden email]]
Sent: Thursday, May 10, 2007 4:11 PM
To: [hidden email]
Subject: Re: IPSocketAddress question


[hidden email] wrote:
> Reinout,
>
> Well I agree. It sure does not make sense for such an OS feature to
> exist; just 64K calls and if the OS were to reserve them all, we are
out
> of ports already. Seems like our communication loop is badly setup,
and
> will need to be changed as I nowrealize.
> No, this is not a publicly documented API, something we are dicussing
> currently for an internal program. It's clear to me that the server
(C++
> in our case) would have to start on an available port and let the
client
> know which port to send the commands on. We can not use a "well known
> port" scheme here as there can be multiple pairs of server-clients
> independent of one another.
>
>  

You may want to have a look at the venerable FTP protocol for
inspiration.

FTP has a command channel and for several commands (GET,PUT)  it will
implicitly create a data channel (a new TCP connection) reporting back
to the client on which port number this connection will appear.
 I nice twist is that the protocol allows for the server (the listening
socket) to be set up on either side of the connection (read up on
'passive mode', the PASV command), this helps with firewall traversal.



HTH,

Reinout
-------