Jump to content
  • Advertisement
Sign in to follow this  
SCarvenger

select() efficiency

This topic is 3901 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Is the select() way the most efficient way to handle sockets? I have heard of I/O completion ports in windows, are they really good? If they are, is there something like this on *nix systems?

Share this post


Link to post
Share on other sites
Advertisement
There are OS-specific APIs in Linux and FreeBSD, like kevent and kqueue.

But there's nothing wrong with select. I believe it's part of what Apache uses, and nobody's complaining about its performance. The thread goes to sleep until there's an event, so no CPU cycles are wasted. It does typically require a multithreaded program if you want anything else going on while the socket is waiting for input, but that's not a big deal.

Share this post


Link to post
Share on other sites
I had been curious about this as well. I'd read in many places that select() was "terrible and inefficient", but I assume this is only in regard to TCP where you have multiple sockets open and you're having to loop through them all. With UDP and only one socket, and an appropriate timeout for select(), is there any real advantage to using IOCP? Or are the OS-specific methods more about throughput?

Share this post


Link to post
Share on other sites
Quote:
It does typically require a multithreaded program if you want anything else going on while the socket is waiting for input, but that's not a big deal.


Actually, you can use select() in polling fashion, and do the other things. Select() will also wake up when you receive signals, so you can use it in a signal-driven UNIX program as well. (Btw: all UNIX programs are intended to be signal drive, but that hasn't been very well followed-through in common practice...)

Quote:
I'd read in many places that select() was "terrible and inefficient"


The Windows implementation of select() isn't very efficient, for two reasons:
1) The FD_SET implementation is O(n-squared).
2) The Windows kernel can only use WaitForMultipleObjects() on up to 64 objects at a time per thread.

On UNIX, select() is pretty good, although it will start showing up on profiles once you have many hundreds of TCP sockets.

Share this post


Link to post
Share on other sites
Quote:
Original post by hplus0603
The Windows implementation of select() isn't very efficient, for two reasons:
1) The FD_SET implementation is O(n-squared).
2) The Windows kernel can only use WaitForMultipleObjects() on up to 64 objects at a time per thread.

On UNIX, select() is pretty good, although it will start showing up on profiles once you have many hundreds of TCP sockets.


So, for a single UDF socket, none of that would be an issue, right? Is there a reason I'm unaware of where a game would need more than a single UDP socket?

Share this post


Link to post
Share on other sites
Depends on what the game is doing. If you do, say, map downloads, or patching, or encrypted reliable streams, then using TCP might be a better idea than trying to build it all yourself on top of UDP.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!