Do you have any specific solution in mind?
--Brian
David Reid wrote:
Can we all come down off the ceiling for a bit and get our feet back on the
ground?
I can't help but wonder why we are making this whole thing so complicated
when people have been using computers and libraries using time quite hap
On Tue, 16 Jul 2002, David Reid wrote:
> BTW, this is getting embarrassing to watch - please can we bring this to a
> head somehow?
Party pooper. ;)
++1!
Ryan
--
Ryan Bloom [EMAIL PROTECTED]
645 Howard St. [EMAIL PROTECTED]
San Francisco, CA
> -Original Message-
> From: David Reid [mailto:[EMAIL PROTECTED]
> Sent: Monday, July 15, 2002 4:36 PM
> To: APR Dev Li
Can we all come down off the ceiling for a bit and get our feet back on the
ground?
I can't help but wonder why we are making this whole thing so complicated
when people have been using computers and libraries using time quite happily
for a number of years without getting as involved as this has g
Cliff Woolley wrote:
On Mon, 15 Jul 2002, Brian Pane wrote:
(seconds << 20) + microseconds
Yeah, but addition and subtraction of the resulting scalars would require
just as many carry/underflow checks as a structure would...
You can rely on normal scalar arithmetic to handle the carry.
T
Cliff Woolley wrote:
On Mon, 15 Jul 2002, Cliff Woolley wrote:
realsecs = 22/21 * (realusecs >> 20) + 22/21;
realsecs = 44/21 * (realusecs >> 20);
I'm obviously on crack. :)
That last line is of course totally wrong and shouldn't have been there.
:)
So what we really end up with is this
Building upon Cliff's formulas, here's another idea
for doing faster conversions of the current apr_time_t
format to seconds:
What we want is t/100
What we can do easily is t/1048576
But what can we add to t/1048576 to approximate t/100?
If I solve for 'C' in
t/100 = t/1048576 + t/C
I
On Mon, Jul 15, 2002 at 03:48:55PM -0400, Cliff Woolley wrote:
> So it's something close to:
>
> realsecs = ((realusecs >> 20) + (realsecs/22) + 1);
>
> Which simplifies out as:
>
> realsecs = 22/21 * ((realusecs >> 20) + 1);
> realsecs = 22/21 * (realusecs >> 20) + 22/21;
> realsecs = 44/21 * (
Attached is the patch to eliminate the new timeout_ms field that
Ryan objected to this morning.
I have no intention of committing it. I do not agree with the sentiment
that it is difficult to track multi-option/multi-value settings when everyone
is using the accessor [e.g. apr_socket_timeout_set()
At 02:15 PM 7/15/2002, Brian Pane wrote:
Bill Stoddard wrote:
Cliff demonstrates that there is significant loss of accuracy using just a
shift. I believe (faith? :-) that there is a simple solution to this. Don't
know what it is just now though...
I think the simple solution is to pack the data int
Cliff Woolley wrote:
On Mon, 15 Jul 2002, Brian Pane wrote:
seconds = (t >> 20) + (t >> 24)
That probably isn't accurate enough, but you get the basic idea:
sum a couple of t/(2^n) terms to approximate t/100.
What do you think?
Sounds like the right idea. But I'm still not sure this i
On Mon, 15 Jul 2002, Brian Pane wrote:
> seconds = (t >> 20) + (t >> 24)
>
> That probably isn't accurate enough, but you get the basic idea:
> sum a couple of t/(2^n) terms to approximate t/100.
>
> What do you think?
Sounds like the right idea. But I'm still not sure this isn't too
compli
On Mon, 15 Jul 2002, Ryan Bloom wrote:
> Ok, cool. I thought I had forgotten something insanely simple about
> basic math. Phew. :-D
Programming, calculus, theory of computation, that stuff is
easy. Arithmetic and algebra, that's hard. =-]
You know you're in trouble when you can't even ma
> On Mon, 15 Jul 2002, Cliff Woolley wrote:
>
> > realsecs = 22/21 * (realusecs >> 20) + 22/21;
> > realsecs = 44/21 * (realusecs >> 20);
>
> I'm obviously on crack. :)
>
> That last line is of course totally wrong and shouldn't have been
there.
> :)
Ok, cool. I thought I had forgotten someth
On Mon, 15 Jul 2002, Cliff Woolley wrote:
> realsecs = 22/21 * (realusecs >> 20) + 22/21;
> realsecs = 44/21 * (realusecs >> 20);
I'm obviously on crack. :)
That last line is of course totally wrong and shouldn't have been there.
:)
On Mon, 15 Jul 2002, Bill Stoddard wrote:
> Cliff demonstrates that there is significant loss of accuracy using just a
> shift. I believe (faith? :-) that there is a simple solution to this. Don't
> know what it is just now though...
More numerical musings:
Without compensation:
1-21 seconds co
On Mon, 15 Jul 2002, Brian Pane wrote:
> (seconds << 20) + microseconds
Yeah, but addition and subtraction of the resulting scalars would require
just as many carry/underflow checks as a structure would...
I mean, that's all that really is: a bitfield.
--Cliff
Bill Stoddard wrote:
Cliff demonstrates that there is significant loss of accuracy using just a
shift. I believe (faith? :-) that there is a simple solution to this. Don't
know what it is just now though...
I think the simple solution is to pack the data into the apr_time_t
using
(seconds << 20)
Title: [PATCH] unix/dso.c on solaris
First time addressing this email address and I have a few questions which I hope someone will take the time to answer.
1. Does anyone know a reason why when loading a shared library on solaris 2.8, flag RTLD_NOW does not work? testdso.c will only work wi
On Mon, 15 Jul 2002, Bill Stoddard wrote:
> > >>3. 64-bit shifts to get approximate seconds
> > >> (fast, but loss of accuracy)
> > >>
> > >>
> > >
> > >If you convert from microseconds to integer seconds (which is what httpd
> > >requires), you loose -resolution- no matter how you do it
> >>3. 64-bit shifts to get approximate seconds
> >> (fast, but loss of accuracy)
> >>
> >>
> >
> >If you convert from microseconds to integer seconds (which is what httpd
> >requires), you loose -resolution- no matter how you do it. If
> the accuracy
> >you loose is smaller than the reso
Bill Stoddard wrote:
Under this proposal, the sequence of time operations in an
httpd request would look like:
1. gettimeofday
(fast, no loss of accuracy)
We cannot avoid this, right?
Right (but it's fast enough that we don't need to worry about it).
2. 64-bit multiplication to bui
> On Mon, 15 Jul 2002, Bill Stoddard wrote:
>
> > > 1. gettimeofday
> > >(fast, no loss of accuracy)
> > We cannot avoid this, right?
>
> Right.
>
> >
> > > 2. 64-bit multiplication to build an apr_time_t
> > >(slow (on lots of current platforms), no loss of accuracy)
> >
>
On Mon, 15 Jul 2002, Bill Stoddard wrote:
> > 1. gettimeofday
> >(fast, no loss of accuracy)
> We cannot avoid this, right?
Right.
>
> > 2. 64-bit multiplication to build an apr_time_t
> >(slow (on lots of current platforms), no loss of accuracy)
>
> Do we eliminate this
Just a heads up; these are the first Win32 warnings in APR in a long time.
apr\poll\unix\poll.c(165) : warning C4244: '=' : conversion from '__int64 '
to 'long ', possible loss of data
apr\poll\unix\poll.c(166) : warning C4244: '=' : conversion from '__int64 ' to
'long ', possible loss of data
ap
> Bill Stoddard wrote:
>
> >New proposal... leave apr_time_t exactly as it is. The
> performance problem
> >is with how we are converting an apr_time_t into a value with 1 second
> >resolution (ie, doing 64 bit divisions). I propose we introduce some new
> >macros (or functions) to efficiently re
Feel free to 'cvs rm' it. If it is only there for reference, people can
get to it from the Attic.
Ryan
--
Ryan Bloom [EMAIL PROTECTED]
645 Howard St. [EMAIL PROTECTED]
San Francisco, CA
> -Original Message-
> Fro
If it isn't used any more and is need only for reference, can we at
least move it somewhere else? Since NetWare uses the Win32 Network_io
source and the unix poll.c, it confuses our make files to find the same
named file in both directories. I keep having to manually delete the
file before I buil
That version isn't used anymore, and it should be removed. I believe
wrowe left it in the directory for reference purposes, and was going to
remove it in time.
Ryan
--
Ryan Bloom [EMAIL PROTECTED]
645 Howard St. [EMAIL PRO
Should the Win32 version of poll.c in the network_io directory be
removed from CVS? If Win32 still uses there own version, shouldn't it
be moved to poll/win32?
Brad
Brad Nicholes
Senior Software Engineer
Novell, Inc., the leading provider of Net business solutions
http://www.novell.com
as IANH_PRETAG1_2040
I'll use this as a basis for 2.0.40 which I'm hoping will be release by
the end of the week
+1 (on both :) )
David Reid wrote:
>
> +1 from me. Let's finish this nonsense!
>
> david
>
> > New proposal... leave apr_time_t exactly as it is. The performance
> problem
> > is with how we are converting an apr_time_t into a value with 1 second
> > resolution (ie, doing 64 bit divisions). I
Bill Stoddard wrote:
New proposal... leave apr_time_t exactly as it is. The performance problem
is with how we are converting an apr_time_t into a value with 1 second
resolution (ie, doing 64 bit divisions). I propose we introduce some new
macros (or functions) to efficiently remove resolution fr
++1 here.
Ryan
--
Ryan Bloom [EMAIL PROTECTED]
645 Howard St. [EMAIL PROTECTED]
San Francisco, CA
> -Original Message-
> From: David Reid [mailto:[EMAIL PROTECTED]
> Sent: Monday, July 15, 2002 8:00 AM
> To: APR D
> From: Bill Stoddard [mailto:[EMAIL PROTECTED]
>
>
> > This will work, and should be portable. Just a question, how big a
> > performance improvement is this? Have we hit the point where we are
> > optimizing code just to optimize code?
>
> This would be a big improvement. A shift is a -lot-
+1 from me. Let's finish this nonsense!
david
> New proposal... leave apr_time_t exactly as it is. The performance
problem
> is with how we are converting an apr_time_t into a value with 1 second
> resolution (ie, doing 64 bit divisions). I propose we introduce some new
> macros (or functions)
> On Sun, Jul 14, 2002 at 10:36:49PM -0500, William A. Rowe, Jr. wrote:
> > If the name apr_time_sec_usec_make(secs, usecs) makes more sense, we
>
> NO! -- justin
>
+1 on the NO!
Bill
> This will work, and should be portable. Just a question, how big a
> performance improvement is this? Have we hit the point where we are
> optimizing code just to optimize code?
This would be a big improvement. A shift is a -lot- cheaper than a 64 bit
division. We could leave apr_time_t exact
New proposal... leave apr_time_t exactly as it is. The performance problem
is with how we are converting an apr_time_t into a value with 1 second
resolution (ie, doing 64 bit divisions). I propose we introduce some new
macros (or functions) to efficiently remove resolution from apr_time_t and
do
> > >>If you mean using only second-resolution times, that's an option,
> > >>but not for the httpd. One of the big problems with 1.3 was that
> > >>the request time was only stored with 1-second resolution. We used
> > >>to have to add in custom, redundant time lookups to get better
> > >>resol
> > From: Thom May [mailto:[EMAIL PROTECTED]
> >
> > * [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote :
> > > wrowe 2002/07/15 00:42:35
> > >
> > > Modified:.renames_pending
> > > Log:
> > > Two down. Don't know if I agree with the entire host of these
> > becoming
> > >
> From: Thom May [mailto:[EMAIL PROTECTED]
>
> * [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote :
> > wrowe 2002/07/15 00:42:35
> >
> > Modified:.renames_pending
> > Log:
> > Two down. Don't know if I agree with the entire host of these
> becoming
> > apr_socket_ foo, b
> >>If you mean using only second-resolution times, that's an option,
> >>but not for the httpd. One of the big problems with 1.3 was that
> >>the request time was only stored with 1-second resolution. We used
> >>to have to add in custom, redundant time lookups to get better
> >>resolution whene
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
>
> wrowe 2002/07/14 23:34:33
>
> Modified:network_io/win32 sendrecv.c
> Log:
> The last transpostion of ->timeout into apr_time fixed a bug
> identified
> by TANAKA Koichi <[EMAIL PROTECTED]>, where we used our
old ms
>
* [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote :
> wrowe 2002/07/15 00:42:35
>
> Modified:.renames_pending
> Log:
> Two down. Don't know if I agree with the entire host of these becoming
> apr_socket_ foo, but, well... I won't argue.
Please do. That was why I commited
[EMAIL PROTECTED] wrote:
On Sun, 14 Jul 2002, Brian Pane wrote:
Ryan Bloom wrote:
BTW, this whole conversation started because we wanted to speed up
Apache. Has anybody considered taking a completely different tack to
solve this problem?
If you mean using only second-resolution t
At 04:34 AM 7/10/2002, INOUE Seiichiro wrote:
Thank you for submitting the patch. We took a slightly different approach,
since some unix common and accessor code rightly [but incorrectly]
assumed that timeout was in usec.
Instead we've reverted to the APR definition of usec's for timeout, and
adde
Justin Erenkrantz wrote:
On Sun, Jul 14, 2002 at 07:42:09PM -0700, Brian Pane wrote:
It's a little more efficient if you put the result in
a struct rather than a scalar, but you still have to do
the carry from the seconds field to the microseconds field
if time1.tv_usec < time2.tv_usec. Minimal
William A. Rowe, Jr. wrote:
At 11:41 PM 7/14/2002, Ryan Bloom wrote:
>
> I'd suggest you snooze, you lose, but of course this is only two
weeks old,
> not two years old.
I am going to ignore this flame bait.
Not flame bait... reminder to myself that this is brand new code...
...there are plenty
[EMAIL PROTECTED] wrote:
I would not support this change, simply because I don't see it making a
huge difference. We are better off fixing the apr_time_t implementation
and then looking for things like this.
I agree. Once we go to the binary microsecond implementation,
what we'll be able t
Ryan Bloom wrote:
We had an IO abstraction layer a long time ago. The original one was
bulky, hard to debug, and didn't solve the problem it was designed to
solve, namely filtering. When the filters were introduced, the IOLs
were removed, because they were no longer needed.
I guess my only questi
On Sun, 14 Jul 2002, Brian Pane wrote:
> Ryan Bloom wrote:
>
> >BTW, this whole conversation started because we wanted to speed up
> >Apache. Has anybody considered taking a completely different tack to
> >solve this problem?
> >
>
> If you mean using only second-resolution times, that's an o
On Mon, 15 Jul 2002, William A. Rowe, Jr. wrote:
> At 10:03 PM 7/14/2002, Ryan Bloom wrote:
>
> >BTW, this whole conversation started because we wanted to speed up
> >Apache. Has anybody considered taking a completely different tack to
> >solve this problem?
> >
> >I know there is a patent on th
Ryan Bloom wrote:
BTW, this whole conversation started because we wanted to speed up
Apache. Has anybody considered taking a completely different tack to
solve this problem?
If you mean using only second-resolution times, that's an option,
but not for the httpd. One of the big problems with 1.
At 10:03 PM 7/14/2002, Ryan Bloom wrote:
BTW, this whole conversation started because we wanted to speed up
Apache. Has anybody considered taking a completely different tack to
solve this problem?
I know there is a patent on this, but I am willing to ignore it, and I
am pretty sure that we can get
Hi, this is a forwarded patch from Marcus Comstedt <[EMAIL PROTECTED]>,
to do unity conversion more efficiently and reliably when xlating. It
looks quite sane to me, and I'd like to apply it. I've posted it here
once before, but there were other discussions going on at the time and
I'm not sure i
At 11:41 PM 7/14/2002, Ryan Bloom wrote:
>
> I'd suggest you snooze, you lose, but of course this is only two weeks old,
> not two years old.
I am going to ignore this flame bait.
Not flame bait... reminder to myself that this is brand new code...
...there are plenty of folks who don't even check t
> >I would not support this change, simply because I don't see it making a
> >huge difference. We are better off fixing the apr_time_t implementation
> >and then looking for things like this.
> >
>
> I agree. Once we go to the binary microsecond implementation,
> what we'll be able to do within
> Evidently Justin has found the second use case. And if you are trying
> to preserve time when udate'ing() on a file, you better know the original
> time if you want to roundtrip.
But that is a *BSD thing only, and they provide the POSIX values already.
> >Four macros, by four different scales
Ryan Bloom wrote:
This will work, and should be portable. Just a question, how big a
performance improvement is this? Have we hit the point where we are
optimizing code just to optimize code?
Based on the profile data, 64-bit divisions *are* a problem,
but I think there's a better solution for th
On Sun, 14 Jul 2002, Justin Erenkrantz wrote:
> On Sun, Jul 14, 2002 at 11:03:45PM -0500, William A. Rowe, Jr. wrote:
> > That is a more frequent case, yes. How httpd stores the return
> > values from apr functions is up to httpd. If all it needs is elapsed
> > seconds, and int suffices quite ni
On Sun, Jul 14, 2002 at 11:03:45PM -0500, William A. Rowe, Jr. wrote:
> That is a more frequent case, yes. How httpd stores the return
> values from apr functions is up to httpd. If all it needs is elapsed
> seconds, and int suffices quite nicely.
>
>
> E.g.
>
> int request_start = apr_time_a
This will work, and should be portable. Just a question, how big a
performance improvement is this? Have we hit the point where we are
optimizing code just to optimize code?
I would not support this change, simply because I don't see it making a
huge difference. We are better off fixing the ap
At 10:56 PM 7/14/2002, Justin Erenkrantz wrote:
On Sun, Jul 14, 2002 at 07:42:09PM -0700, Brian Pane wrote:
> It's a little more efficient if you put the result in
> a struct rather than a scalar, but you still have to do
> the carry from the seconds field to the microseconds field
> if time1.tv_us
On Sun, Jul 14, 2002 at 07:42:09PM -0700, Brian Pane wrote:
> It's a little more efficient if you put the result in
> a struct rather than a scalar, but you still have to do
> the carry from the seconds field to the microseconds field
> if time1.tv_usec < time2.tv_usec. Minimally, subtraction
> of
Is this at all portable? I'm making the approximation that n>>10 is
about the same as a /1000, and since apr_poll() isn't guaranteed to be
that accurate, this should be a good chance for an optimization, right?
-aaron
Index: srclib/apr/poll/unix/poll.c
===
On Sun, Jul 14, 2002 at 10:36:49PM -0500, William A. Rowe, Jr. wrote:
> If the name apr_time_sec_usec_make(secs, usecs) makes more sense, we
NO! -- justin
> On Sun, Jul 14, 2002 at 07:54:23PM -0700, Ryan Bloom wrote:
> > BTW, nsec is completely bogus. There isn't an OS that I know of
that
> > reports nsec intervals. Windows comes the closest with 100 nsec
chunks,
>
FWIW, you can do better on Windows with QueryPerformanceFrequency &
QueryPerformanc
At 10:09 PM 7/14/2002, Ryan Bloom wrote:
On Sun, 14 Jul 2002, William A. Rowe, Jr. wrote:
> At 09:54 PM 7/14/2002, Ryan Bloom wrote:
> >The macros are no faster than the constant. The implementation is
> >faster. Completely different.
>
> This statement really confused me. Please explain.
You ma
At 09:54 PM 7/14/2002, Ryan Bloom wrote:
> apr_time_xmake(sec, xsec);
>
> So xsec can be an nsec, usec or msec, depending on the app.
> So WHAT? They all follow an incredibly simple pattern.
BTW, nsec is completely bogus. There isn't an OS that I know of that
reports nsec intervals. Windows come
Aaron Bannert wrote:
The reason we don't use a struct (timeval or any variant thereof)
is that doing addition and subtraction on the struct is much slower,
more complicated, and (if people try to do their own match on the
struct directly) more error-prone than doing the same ops on a
scalar.
H
On Sun, 14 Jul 2002, Justin Erenkrantz wrote:
> On Sun, Jul 14, 2002 at 07:54:23PM -0700, Ryan Bloom wrote:
> > BTW, nsec is completely bogus. There isn't an OS that I know of that
> > reports nsec intervals. Windows comes the closest with 100 nsec chunks,
>
> On *BSD platforms, stat() returns
On Sun, Jul 14, 2002 at 07:54:23PM -0700, Ryan Bloom wrote:
> BTW, nsec is completely bogus. There isn't an OS that I know of that
> reports nsec intervals. Windows comes the closest with 100 nsec chunks,
On *BSD platforms, stat() returns nanoseconds in a timespec struct
or in the st_?timensec v
On Sun, 14 Jul 2002, William A. Rowe, Jr. wrote:
> At 09:54 PM 7/14/2002, Ryan Bloom wrote:
> >The macros are no faster than the constant. The implementation is
> >faster. Completely different.
>
> This statement really confused me. Please explain.
You made the statement that the macros were
At 09:54 PM 7/14/2002, Ryan Bloom wrote:
The macros are no faster than the constant. The implementation is
faster. Completely different.
This statement really confused me. Please explain.
For clarity, there is only one reason that we aren't just using POSIX's
time_t. While Windows has time_t, it doesn't use time_t's internally.
Instead, it uses a completely different epoch with 100 nano-second
resolution.
The only other reason for apr_time_t is to get usec resolution.
> From: Aa
At 09:35 PM 7/14/2002, Aaron Bannert wrote:
On Sun, Jul 14, 2002 at 07:27:04PM -0700, Brian Pane wrote:
How exactly is the subtraction slower?I'm not at all sure what you
mean by people matching on the struct directly...
For addition...
rtm.sec = tm1.sec + tm2.sec;
rtm.usec = tm1.usec + tm2.usec;
i
> From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED]
>
> At 03:21 PM 7/14/2002, Ryan Bloom wrote:
>
> >So my names are wrong, but the concept is the same. More macros than
> >you can keep straight to fill in the time structure. The advantage
to
> >the current model, is that there is one macro:
On Sun, Jul 14, 2002 at 07:27:04PM -0700, Brian Pane wrote:
> You're thinking of timeval; time_t is just a long int containing
> seconds since the start of the epoch.
Yes, thanks. :)
> The reason we don't use a struct (timeval or any variant thereof)
> is that doing addition and subtraction on th
Aaron Bannert wrote:
Can someone remind me what the reasons are that we don't use a struct
with separate elements for seconds and microseconds, ala time_t?
You're thinking of timeval; time_t is just a long int containing
seconds since the start of the epoch.
The reason we don't use a struct (tim
Can someone remind me what the reasons are that we don't use a struct
with separate elements for seconds and microseconds, ala time_t?
-aaron
At 03:21 PM 7/14/2002, Ryan Bloom wrote:
I can accept apr_time.
>
> They won't. They will ask WTF is a busec? They will look, and
discover that
> it's a binary usec. In the doc sections for both apr_time and
apr_timediff/span
> we point them @see {group} apr_time_macros. There they find all t
At 07:30 PM 7/14/2002, Ryan Bloom wrote:
On Sun, 14 Jul 2002, Ryan Bloom wrote:
You are right that it doesn't help with binary compat, but we haven't
committed to binary compat until 1.0 is released BTW.
True. All binary compatibility so far is nothing but experimental,
proof of concept to help wo
We had an IO abstraction layer a long time ago. The original one was
bulky, hard to debug, and didn't solve the problem it was designed to
solve, namely filtering. When the filters were introduced, the IOLs
were removed, because they were no longer needed.
I guess my only question, is what probl
I know this topic has come up several times in the past,
but I can't remember the outcome/reasoning on why we didn't
want to re-introduce the IO Layer for file operations..
TIA
Ian
On Sun, 14 Jul 2002, Ryan Bloom wrote:
> > > How to resolve Aaron's veto? The #ifndef NEW_TIME_FMT thing is
> > > interesting. :)
> >
> > How does that help me though? Wouldn't that mean that APR would be
> linked
> > with the new time implementation and the older app would link in just
> > fin
86 matches
Mail list logo
