Prev: [Fedora 12] Throw out my parallel port flatbed scanner?
Next: program for cybercafe
From: Karthik Balaguru on 16 Feb 2010 11:15
On Feb 16, 5:43 am, Wolfgang Draxinger <wdraxin...(a)darkstargames.de>
wrote:
> Karthik Balaguru wrote:
> > Every call to a function will consume some
> > instructions on any processor.
>
> What matters is the work actually done. Even if you combined socket(...) and
> bind(...) into a single call, all the tasks of both socket and bind still
> would need to be done.

Yes, but there can be some saving in the
function calls and the arguments being passed
that inturn could result in little bit of improvement.
Yes, the benefit is less.

> Now just take a look how many subcalls both
> socket(...) and bind(...) do: It's in the order of some hundreds. Compared
> to this these little two separate calls contribute almost nothing.
>

:-) :-)

> > 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.
>
> You're talking about micro optimization here, some technique that seldomly
> gains you something. socket(...) ... bind(...) are both CPU bound, but
> server applications normally suffer on the I/O side, so if I were to
> optimize something, I'd start there.
>

Interesting point of view, as the earlier is micro
optimization that provides less gain.

Karthik Balaguru
From: David Schwartz on 16 Feb 2010 11:58
On Feb 16, 8:11 am, Karthik Balaguru <karthikbalagur...(a)gmail.com>
wrote:

> Yes, It appears to be just combining two functions,
> but i think there are other things to consider that
> improves it a bit.
> Even the number of arguments to the new call
> can be minimized by clubbing many elements
> and using structures to pass by reference.
> So, the number of calls and the arguments
> being passed gets reduced.

How will that reduce the number of arguments passed? The new combined
function will still have to call some equivalent of 'socket' and pass
it the same parameters and then call some equivalent of 'bind' and
pass it the same parameters. The only difference will be that a new
function will be added to the call path.

I still don't see where any benefit or savings would come from.

Again, as I said, to argue there's some kind of savings you'd have to
point out some benefit from combining the functions. For example,
there might be some savings if socket is internally implemented like
this:

1) Allocate internal socket.
2) Lock process socket table.
3) Assign process socket handle.
4) Unlock process socket table.
5) Return handle.

And bind is implemented like this:

1) Lock process socket table.
2) Look up handle in table.
3) Unlock process socket table.
4) Call internal bind function.
5) Return results.

Then your internal function could avoid some steps if implemented like
this:

1) Allocate internal socket.
2) Call internal bind function.
3) Lock process socket table.
4) Assign process socket handle.
5) Unlock process socket table.
6) Return results.

See how here there is an actual savings? "It saves a call by adding a
call" (since it has to call socket and bind internal functions) is not
a savings. Only "it avoids some work that would otherwise be done
twice" is a savings.

But, on the flip side, you have some added complexity with this. If
step 4 fails, you have already bound when you should not have. Some
protocols do not make it possible to instantaneously tear down a
binding and you may have to clean up pending connections.

So my bet is that these optimizations wouldn't actually work out in
practice and the added overhead of handling different error cases and
releases the socket on bind failure would make it totally not worth
it.

DS
From: Karthik Balaguru on 17 Feb 2010 13:05
On Feb 16, 9:58 pm, David Schwartz <dav...(a)webmaster.com> wrote:
> On Feb 16, 8:11 am, Karthik Balaguru <karthikbalagur...(a)gmail.com>
> wrote:
>
> > Yes, It appears to be just combining two functions,
> > but i think there are other things to consider that
> > improves it a bit.
> > Even the number of arguments to the new call
> > can be minimized by clubbing many elements
> > and using structures to pass by reference.
> > So, the number of calls and the arguments
> > being passed gets reduced.
>
> How will that reduce the number of arguments passed? The new combined
> function will still have to call some equivalent of 'socket' and pass
> it the same parameters and then call some equivalent of 'bind' and
> pass it the same parameters. The only difference will be that a new
> function will be added to the call path.
>
> I still don't see where any benefit or savings would come from.
>
> Again, as I said, to argue there's some kind of savings you'd have to
> point out some benefit from combining the functions. For example,
> there might be some savings if socket is internally implemented like
> this:
>
> 1) Allocate internal socket.
> 2) Lock process socket table.
> 3) Assign process socket handle.
> 4) Unlock process socket table.
> 5) Return handle.
>
> And bind is implemented like this:
>
> 1) Lock process socket table.
> 2) Look up handle in table.
> 3) Unlock process socket table.
> 4) Call internal bind function.
> 5) Return results.
>
> Then your internal function could avoid some steps if implemented like
> this:
>
> 1) Allocate internal socket.
> 2) Call internal bind function.
> 3) Lock process socket table.
> 4) Assign process socket handle.
> 5) Unlock process socket table.
> 6) Return results.
>
> See how here there is an actual savings? "It saves a call by adding a
> call" (since it has to call socket and bind internal functions) is not
> a savings. Only "it avoids some work that would otherwise be done
> twice" is a savings.
>
> But, on the flip side, you have some added complexity with this. If
> step 4 fails, you have already bound when you should not have. Some
> protocols do not make it possible to instantaneously tear down a
> binding and you may have to clean up pending connections.
>
> So my bet is that these optimizations wouldn't actually work out in
> practice and the added overhead of handling different error cases and
> releases the socket on bind failure would make it totally not worth
> it.
>

Okay.

Karthik Balaguru

From: Karthik Balaguru on 17 Feb 2010 13:17
On Feb 17, 8:58 am, Maxwell Lol <nos...(a)com.invalid> wrote:
> Karthik Balaguru <karthikbalagur...(a)gmail.com> writes:
> >> What if you want to do something to the socket before you bind it?
> > In which context ?
>
> See setsockopt(2)
>
> For instance, you may want to set the receive buffer in a TCP to a
> larger value.  This is important on long fat networks, such as when
> the ping time is > 500 milliseconds, as in satellite connections.
>
> Or you may want to set the broadcast flag for UDP sockets.
>

Interestingly, yes, i do find that setsockopt() manipulates
the options associated with a socket. I think, this point seems
to be very important as the options affect the socket operations
such as the routing of packets, out-of-band data (data marked
Urgent), lingering of socket if data is present, Send/Receive
buffer size, Keepalive(if supported by protocol) features.
Thx for the tip !

>
> > 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.

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