Prev: [Fedora 12] Throw out my parallel port flatbed scanner?
Next: program for cybercafe
From: Karthik Balaguru on 14 Feb 2010 16:21
Hi,
I have been trying to optimize some code.
I came across a thought as below -
I wonder why Socket and Bind are separate
in the case of Server ?
Why can't the Socket call create the address
directly for the newly created socket instead
of doing it via a Bind call ? Any ideas ?

I think that this will be a good optimization point
to consider as it could save some instruction
cycles .

Thx in advans,
Karthik Balaguru
From: Wolfgang Draxinger on 14 Feb 2010 17:03
Karthik Balaguru wrote:

> Hi,
> I have been trying to optimize some code.

Did you profile it before?

> I came across a thought as below -
> I wonder why Socket and Bind are separate
> in the case of Server?
> Why can't the Socket call create the address
> directly for the newly created socket instead
> of doing it via a Bind call ? Any ideas ?

Because there are not just server socket. A socket may be used in many
different ways. Packing it all into one single call is a very bad idea.

>
> I think that this will be a good optimization point
> to consider as it could save some instruction
> cycles.

Optimization happens on the protocol/implementation level, not the
instruction level. You start there, you're on the wrong track.

Again: Did you profile the program? Is it in fact CPU bound? Did you compare
the huge workload performed by both socket(...) and bind(...) to the little
work that is done inbetween? And even if socket(...) and bind(...) were
merged the overall workload would about the same.


Wolfgang

From: David Schwartz on 15 Feb 2010 01:08
On Feb 14, 1:21 pm, Karthik Balaguru <karthikbalagur...(a)gmail.com>
wrote:
> Hi,
> I have been trying to optimize some code.
> I came across a thought as below -
> I wonder why Socket and Bind are separate
> in the case of Server ?
> Why can't the Socket call create the address
> directly for the newly created socket instead
> of doing it via a Bind call ? Any ideas ?

What if you want to do something to the socket before you bind it?
What if you don't want to bind it? What if 'socket' needs to return an
error code? What if you need to obtain information about the socket
before you know how to bind it?

> I think that this will be a good optimization point
> to consider as it could save some instruction
> cycles .

Where would the savings come from exactly?

DS
From: Karthik Balaguru on 15 Feb 2010 15:25
On Feb 15, 11:08 am, David Schwartz <dav...(a)webmaster.com> wrote:
> On Feb 14, 1:21 pm, Karthik Balaguru <karthikbalagur...(a)gmail.com>
> wrote:
>
> > Hi,
> > I have been trying to optimize some code.
> > I came across a thought as below -
> > I wonder why Socket and Bind are separate
> > in the case of Server ?
> > Why can't the Socket call create the address
> > directly for the newly created socket instead
> > of doing it via a Bind call ? Any ideas ?
>
> What if you want to do something to the socket before you bind it?
In which context ?
Normally it is creation of a socket, get the descriptor
and associate the socket with a port & a address.

> What if you don't want to bind it?
Here, on the server side, we might be going in for
both socket & bind calls. Hence they can be merged.
But, there are scenarios on the client side that
might not require a bind. I too had the same thought
and hence only making it specific to the server side.

> What if 'socket' needs to return an
> error code?

It can be handled.
This can be at the end of the combination
of socket & bind. It can specify socket
specific error codes and bind specific
error codes.

> What if you need to obtain information about the socket
> before you know how to bind it?
>

Are you conveying about the AF_INET and AF_LOCAL
related typecasting differences ?
Normally, bind is about associating the socket id with
an address and port number.

> > I think that this will be a good optimization point
> > to consider as it could save some instruction
> > cycles .
>
> Where would the savings come from exactly?
>

Every call to a function will consume some
instructions on any processor. So, normally
few related functions can be merged. I think, the
same can be thought of here w.r.t server side alone.

It is not a very big saving, but just few savings.

Thx in advans,
Karthik Balaguru
From: David Schwartz on 15 Feb 2010 16:24
On Feb 15, 12:25 pm, Karthik Balaguru <karthikbalagur...(a)gmail.com>
wrote:

> > What if you want to do something to the socket before you bind it?

> In which context ?
> Normally it is creation of a socket, get the descriptor
> and associate the socket with a port & a address.

Right, but what if you want to do something *before* you bind it? For
example, you may want to setup port reuse. You may want to change
default buffer sizes.

> > What if you don't want to bind it?

> Here, on the server side, we might be going in for
> both socket & bind calls. Hence they can be merged.
> But, there are scenarios on the client side that
> might not require a bind. I too had the same thought
> and hence only making it specific to the server side.

But then there is no savings. If you still need a separate 'socket'
call and a 'bind' call, what can the combined call do other than call
'socket' and then call 'bind', which is what you already do. So all it
would do is add an *extra* call. Now, you call 'socket', then you call
'bind'. With the suggested change, you'd call some function that would
first call 'socket' and then call 'bind'. So two calls would go up to
three.

> > What if 'socket' needs to return an
> > error code?

> It can be handled.
> This can be at the end of the combination
> of socket & bind. It can specify socket
> specific error codes and bind specific
> error codes.

So now there's an extra test between socket and bind. So now the cost
is getting higher.

Old system: Call socket, check for error, call bind, check for error.

New system: Call new call. It calls socket, checks for error, calls
bind, returns. We have to check if the error is a socket error or a
bind error.

Wow, what a savings!

> > > I think that this will be a good optimization point
> > > to consider as it could save some instruction
> > > cycles .

> > Where would the savings come from exactly?

> Every call to a function will consume some
> instructions on any processor. So, normally
> few related functions can be merged. I think, the
> same can be thought of here w.r.t server side alone.

But since you still need a separate 'socket' and 'bind', all you've
done is add a layer of indirection. You haven't suggested any reason
to think the combination will save anything.

> It is not a very big saving, but just few savings.

It's no savings, since you have the added overhead of a new combined
function which still calls the two internal functions. If you want to
argue that there would be a savings, you actually have to do that. For
example, you can argue that the 'bind' call could already know the
internal socket structure rather than having to look it up in the
process' socket table. But just combining two functions into one
doesn't reduce overhead, it increases it by adding an extra function
call.

DS
 |  Next  |  Last
Pages: 1 2 3
Prev: [Fedora 12] Throw out my parallel port flatbed scanner?
Next: program for cybercafe