Re: [network] An RFC posted to the sandbox
Hi Bob,
Caleb Epstein writes:
As far as the appropriate subseconds type goes, we should probably pick the highest-possible resolution that makes sense, which I'd contend is probably microseconds. Some operating systems may be able to slice time (and signal events) at resolutions below milliseconds, but I doubt any can go deeper than microseconds.
I wouldn't take that bet. I know Mac OS X can measure time as finely as nanoseconds (but I have no idea how many services, i.e. sockets, actually work at nanosecond resolutions; it doesn't seem outside the realm of possibility that, given the way technologies advance, that within a few short years, microseconds simply won't be fine enough. One of the nice things about double-as-time-unit is that it avoids resolution issues altogether.
With processor speed basically stalled out around 4GHz, it is at theoretically possible to measure time to about 0.25ns. Not that a scheduler would muck about at that level. For timeout purposes (especially for networking), I think microsec is fine. In particular, this is what select() wants. epoll_wait uses milliseconds. Windows generally uses milliseconds. The kqueue/kevent folks do want nanoseconds. The precision of the implementation is not clear (just it's interface). Having said that, I like Caleb's proposal to offer multiple ctors for timeout purposes as long as they don't get ambiguous. That way, floating point can be used as well as pure integer (if that kind of thing still matters to anyone<g>). Best, Don __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/
Don G <dongryphon <at> yahoo.com> writes:
Hi Bob,
Caleb Epstein writes:
As far as the appropriate subseconds type goes, we should probably pick the highest-possible resolution that makes sense, which I'd contend is probably microseconds. Some operating systems may be able to slice time (and signal events) at resolutions below milliseconds, but I doubt any can go deeper than microseconds.
I wouldn't take that bet. I know Mac OS X can measure time as finely as nanoseconds (but I have no idea how many services, i.e. sockets, actually work at nanosecond resolutions; it doesn't seem outside the realm of possibility that, given the way technologies advance, that within a few short years, microseconds simply won't be fine enough. One of the nice things about double-as-time-unit is that it avoids resolution issues altogether.
With processor speed basically stalled out around 4GHz, it is at theoretically possible to measure time to about 0.25ns.
The end of Moore's law has been predicted for many years; I don't see any reason to believe that processor speeds will stay stalled at 4GHz for long.
Not that a scheduler would muck about at that level.
Agreed.
For timeout purposes (especially for networking), I think microsec is fine.
Also agreed.
In particular, this is what select() wants. epoll_wait uses milliseconds. Windows generally uses milliseconds. The kqueue/kevent folks do want nanoseconds. The precision of the implementation is not clear (just it's interface).
And it's the interface we're discussing. I have no idea of the implementation uses nanosecond precision, but I don't think that matters very much. What matters is an interface that lets users succinctly communicate their intentions.
Having said that, I like Caleb's proposal to offer multiple ctors for timeout purposes as long as they don't get ambiguous. That way, floating point can be used as well as pure integer (if that kind of thing still matters to anyone<g>).
I'd rather approach it the other way around. Instead of saying, "Let's provide various constructors in case someone wants them", we should say "Let's provide a constructor if we know there is a demonstrated, reasonable need for it." Is there a reasonable need for mutliple constructors which allow a user to specify time values in multiple ways? As for ambiguity, there's ambiguity to the compiler, which can probably be worked around, and then there's ambiguity to a human, which can be much more difficult to deal with. In another post, I wrote as an example: timeout t(100); Is this 100 seconds? 100 milliseconds? 100 microseconds? With a single constructor using a type like double with a very simple meaning (i.e., seconds), there is no reader ambiguity, and the interface becomes very simple. At the same time, implementing it (converting to the underlying platform representation) is trivial. If it were me, I'd think long and hard about whether any other constructors are really necessary. Anyway, like I also said in that other post, I don't have strong opinions about the network library -- I'm far from an expert on networking. I do have opinions about library and interface design, however, which is what motivated my comments in the first place. But my hat's off to anyone who would undertake the effort to produce a cross-platform networking library; since I won't be involved, take what I say with a grain of salt, and do what you think is best. Bob
Bob Bell wrote:
The end of Moore's law has been predicted for many years; I don't see any reason to believe that processor speeds will stay stalled at 4GHz for long.
This times the reasons are more fundamentaal than ever before; an unforeseen limitation in the speed of light seems to be the culprit :o). http://www.techworld.com/opsys/news/index.cfm?NewsID=3477 Andrei
Andrei Alexandrescu (See Website For Email) wrote:
Bob Bell wrote:
The end of Moore's law has been predicted for many years; I don't see any reason to believe that processor speeds will stay stalled at 4GHz for long.
Moore`s law is about "Number of components per integrated function" or "Number of components per integrated circuit" (see original paper ftp://download.intel.com/research/silicon/moorespaper.pdf ) The increasing of processor speed was only a "side effect".
This times the reasons are more fundamentaal than ever before; an unforeseen limitation in the speed of light seems to be the culprit :o).
Increasing the size of a circuit there is no physical limit which blocks Moore's law. But your are right, the combination of the physical limits "Number of components per area" and "speed of light" results in a limited processor speed.
Andrei
Here the theoretical upper limit of processor speed: 1. distance between to transistors: s = 10^-10 m (size of a atom) 2. Speed of light c = 3*10^8 m/s ~ 10^9 m/s (I'm interested in the upper limit) travel time of a signal: t = s / c = 10^-10 m / (10^9 m/s) = 10^(-10-9) s = 10^-19 s Processor speed 1/t: 1/t = 10^19 Hz = 10^10 * 10^9 Hz = 10 billion GHz So there is much room to increase processor speed. Peter
Peter Kümmel wrote:
Moore`s law is about "Number of components per integrated function" or "Number of components per integrated circuit" (see original paper ftp://download.intel.com/research/silicon/moorespaper.pdf )
The increasing of processor speed was only a "side effect".
That's true; I glossed over that detail. Nowadays we're not as good anymore in increasing speed, while we stay reasonably strong at increasing density. But the two are related: to make effective use of more transistors you need to have data to keep them busy, so you need speedy transportation of data around.
Increasing the size of a circuit there is no physical limit which blocks Moore's law.
As the article says. Notice that wafer size, however, hasn't grown exponentially during the years. Crystal defects are a killer.
Here the theoretical upper limit of processor speed:
1. distance between to transistors: s = 10^-10 m (size of a atom) 2. Speed of light c = 3*10^8 m/s ~ 10^9 m/s (I'm interested in the upper limit)
Interesting approximation :o)
travel time of a signal: t = s / c = 10^-10 m / (10^9 m/s) = 10^(-10-9) s = 10^-19 s
Processor speed 1/t: 1/t = 10^19 Hz = 10^10 * 10^9 Hz = 10 billion GHz
So there is much room to increase processor speed.
There are, of course, many fundamental (just as theoretical) issues that this overly optimistic calculation neglects: crystal defects, thermal effects, current density (already beyond nuclear reactor level in today's processors), communication complexity, tunnel effects, quantum effects... before long, orders of magnitude fall off rather quickly. Andrei
I forgot, you need a clock signal: s = 1 cm 1/t = c / s = 3 10^8 m/s / 10^-2 m = 30 GHz
"Bob Bell" <belvis@pacbell.net> wrote
I'd rather approach it the other way around. Instead of saying, "Let's provide various constructors in case someone wants them", we should say "Let's provide a constructor if we know there is a demonstrated, reasonable need for it." Is there a reasonable need for mutliple constructors which allow a user to specify time values in multiple ways?
As for ambiguity, there's ambiguity to the compiler, which can probably be worked around, and then there's ambiguity to a human, which can be much more difficult to deal with. In another post, I wrote as an example:
timeout t(100);
Is this 100 seconds? 100 milliseconds? 100 microseconds? With a single constructor using a type like double with a very simple meaning (i.e., seconds), there is no reader ambiguity, and the interface becomes very simple. At the same time, implementing it (converting to the underlying platform representation) is trivial. If it were me, I'd think long and hard about whether any other constructors are really necessary.
Sounds like you need a UDT for time. See http://www.servocomm.freeserve.co.uk/Cpp/physical_quantity/index.html time::ys to time::yr ( 1 yoctosecond = 1e-24 s) OTOH I believe the boost date_time lib also has various udts for time regards Andy Little
On Sat, 16 Apr 2005 22:11:07 +0100, Andy Little wrote
"Bob Bell" <belvis@pacbell.net> wrote
I'd rather approach it the other way around. Instead of saying, "Let's provide various constructors in case someone wants them", we should say "Let's provide a constructor if we know there is a demonstrated, reasonable need for it." Is there a reasonable need for mutliple constructors which allow a user to specify time values in multiple ways?
As for ambiguity, there's ambiguity to the compiler, which can probably be worked around, and then there's ambiguity to a human, which can be much more difficult to deal with. In another post, I wrote as an example:
timeout t(100);
Is this 100 seconds? 100 milliseconds? 100 microseconds? With a single constructor using a type like double with a very simple meaning (i.e., seconds), there is no reader ambiguity, and the interface becomes very simple. At the same time, implementing it (converting to the underlying platform representation) is trivial. If it were me, I'd think long and hard about whether any other constructors are really necessary.
Sounds like you need a UDT for time.
See http://www.servocomm.freeserve.co.uk/Cpp/physical_quantity/index.html
time::ys to time::yr ( 1 yoctosecond = 1e-24 s)
OTOH I believe the boost date_time lib also has various udts for time
Yep. The generalized type is time_duration, but there a bunch of unit types so you can say things like: time_duration td = seconds(10) + milliseconds(20) - nanoseconds(100); So you can write your signature as: void f(boost::posix_time::time_duration td); and your clients can use all the other types to make their code clear. Jeff
participants (6)
-
Andrei Alexandrescu (See Website For Email) -
Andy Little -
Bob Bell -
Don G -
Jeff Garland -
Peter Kümmel