This is a great improvement. It will remove one allocation in the fast path on ...
13 years, 4 months ago
(2011-11-02 21:46:26 UTC)
#3
This is a great improvement. It will remove one allocation in the fast
path on net.Conn.Read/Write. Why is it necessary to FLUSH() the return
value, can runtime.nanotime cause a scheduling event ?
On Thu, Nov 3, 2011 at 8:37 AM, David Symonds <dsymonds@golang.org> wrote:
> LGTM
>
> Seems odd to put the C code for pkg time in the runtime dir, though.
>
On Wed, Nov 2, 2011 at 17:46, Dave Cheney <dave@cheney.net> wrote: > This is a ...
13 years, 4 months ago
(2011-11-02 21:49:24 UTC)
#4
On Wed, Nov 2, 2011 at 17:46, Dave Cheney <dave@cheney.net> wrote:
> This is a great improvement. It will remove one allocation in the fast
> path on net.Conn.Read/Write. Why is it necessary to FLUSH() the return
> value, can runtime.nanotime cause a scheduling event ?
FLUSH tricks the C compiler into writing the value
to the slot on the stack where Go expects to find
the return value.
Thanks for explanation, I was thinking that FLUSH caused a memory fence. On Thu, Nov ...
13 years, 4 months ago
(2011-11-02 21:51:53 UTC)
#5
Thanks for explanation, I was thinking that FLUSH caused a memory fence.
On Thu, Nov 3, 2011 at 8:49 AM, Russ Cox <rsc@golang.org> wrote:
> On Wed, Nov 2, 2011 at 17:46, Dave Cheney <dave@cheney.net> wrote:
>> This is a great improvement. It will remove one allocation in the fast
>> path on net.Conn.Read/Write. Why is it necessary to FLUSH() the return
>> value, can runtime.nanotime cause a scheduling event ?
>
> FLUSH tricks the C compiler into writing the value
> to the slot on the stack where Go expects to find
> the return value.
>
http://codereview.appspot.com/5297078/diff/1001/src/pkg/runtime/runtime.c File src/pkg/runtime/runtime.c (right): http://codereview.appspot.com/5297078/diff/1001/src/pkg/runtime/runtime.c#newcode670 src/pkg/runtime/runtime.c:670: time·Nanoseconds(int64 ret) i'd be happier if this were in ...
13 years, 4 months ago
(2011-11-02 22:50:47 UTC)
#7
PTAL I moved the time stuff into time.goc, which is the canonical way to provide ...
13 years, 4 months ago
(2011-11-03 16:08:57 UTC)
#8
PTAL
I moved the time stuff into time.goc, which is the
canonical way to provide some stuff for another package
from runtime.
I also dropped gettime and converted the assembly for
Darwin, FreeBSD, Linux, and OpenBSD to be nanotime.
I hope someone will tell me what Windows should look like.
Russ
GetSystemTimeAsFileTime is what currently provides the time to time.Nanoseconds. The FileTime is then converted with ...
13 years, 4 months ago
(2011-11-03 16:56:13 UTC)
#9
GetSystemTimeAsFileTime is what currently provides the time to time.Nanoseconds.
The FileTime is then converted with func (ft *Filetime) Nanoseconds() int64 in
syscall/ztypes_windows.go.
Issue 5297078: code review 5297078: time: faster Nanoseconds call
(Closed)
Created 13 years, 4 months ago by rsc
Modified 13 years, 4 months ago
Reviewers:
Base URL:
Comments: 5