Prev: [Fedora 12] Throw out my parallel port flatbed scanner?
Next: program for cybercafe
From: Wolfgang Draxinger on 15 Feb 2010 19:43
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. 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.


Wolfgang

From: Maxwell Lol on 16 Feb 2010 22:58
Karthik Balaguru <karthikbalaguru79(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.





> 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: Maxwell Lol on 16 Feb 2010 23:05
Karthik Balaguru <karthikbalaguru79(a)gmail.com> writes:

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

Well, considering that you have to handle every possible combination
of UNIX domain sockets, TCP sockets, UDP sockets, DCCP, Appletalk, multicast,
broadcast, etc. And there is the linger, keepalive, send and receive
buffer, and reuse options.

And the differences between a client and a server socket.


If you had ONE call, the parsing of all of the different combinations
possible would be significant, and expensive because it's done in the
kernel instead of the user mode. Plus the error handling would also be
made much more complicated. This also complicated the user code that
has to handle the error and try to resolve how to report/fix it.

If you want, write a library or a macro to make it easier to code, go ahead.





From: Karthik Balaguru on 16 Feb 2010 11:11
On Feb 16, 2:24 am, David Schwartz <dav...(a)webmaster.com> wrote:
> 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.
>

New system : Call new call(replacement for socket call,
let it be termed as 'sockbind'.Here it will create the socket
and will also do bind), Check error.

By having error specific return values, can avoid the
checking to determine if it is a socket error or bind error.

It can be as below -
1.Unix domain socket(few characters ) -
sockbind (int domain, int type, int protocol, (struct sockaddr *)
&addr, length)

2.Unix domain socket(more characters) -
sockbind (int domain, int type, int protocol, (struct sockaddr_un *)
&addr, length)

3.Internet domain socket -
sockbind (int domain, int type, int protocol, (struct sockaddr_in *)
&addr, length)

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

That new call might be useful only on server side.

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

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.

But, yes the amount of benefit is less !!

Karthik Balaguru.
From: Rajkumar M on 16 Feb 2010 07:14
server applications normally suffer on the I/O side, so if I were to
> optimize something, I'd start there.

are you referring to TCP offload engine?


--

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