Re: [go-nuts] Re: is it possible to speed up type assertion?

[larytet]

This logger https://github.com/ScottMansfield/nanolog is roughly 2x faster 
than ZAP and will work on all Go platforms.

I want my logs to be collected and stored. I do not want to think where and 
when I can or can not log.  300ns and up (and not deterministic in my 
tests) blocking call is something I would like to avoid. I can run a 
separate log in every thread and reorder, merge the logs offline. When I 
need to actually read the log I can spend quite lot of time to decode the 
data.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: is it possible to speed up type assertion?

[robert engels]

Why are you putting the ResetTimer() and StopTimer() calls in there ? 
Unnecessary AFAIK.

Also, all this test is benchmarking is the time it takes to construct a Field 
struct. What is the point ?

> On Nov 26, 2018, at 1:47 PM, lary...@gmail.com wrote:
> 
> Talking about loggers and ZAP (interesting idea to accommodate API to the 
> JSON)
> The following code gets 40ns/op 
> type FieldType uint8
> 
> type Field struct {
> Key   string
> Type  FieldType
> Integer   int64
> Stringstring
> Interface interface{}
> }
> 
> const (
> // UnknownType is the default field type. Attempting to add it to an 
> encoder will panic.
> UnknownType FieldType = iota
> // Int64Type indicates that the field carries an int64.
> Uint64Type
> )
> 
> func Uint64(key string, val uint64) Field {
> return Field{Key: key, Type: Uint64Type, Integer: int64(val)}
> }
> 
> func handleFields(s string, fields ...Field) {
> 
> }
> 
> func BenchmarkZapApi(b *testing.B) {
> b.ResetTimer()
> for i := 0; i < b.N; i++ {
> handleFields("Hello ",
> Uint64("world", 0),
> Uint64("world", 1),
> Uint64("world", 2),
> )
> }
> b.StopTimer()
> }
> 
> 
> 
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com 
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: is it possible to speed up type assertion?

[larytet]

Talking about loggers and ZAP (interesting idea to accommodate API to the 
JSON)
The following code gets 40ns/op 
type FieldType uint8

type Field struct {
Key   string
Type  FieldType
Integer   int64
Stringstring
Interface interface{}
}

const (
// UnknownType is the default field type. Attempting to add it to an 
encoder will panic.
UnknownType FieldType = iota
// Int64Type indicates that the field carries an int64.
Uint64Type
)

func Uint64(key string, val uint64) Field {
return Field{Key: key, Type: Uint64Type, Integer: int64(val)}
}

func handleFields(s string, fields ...Field) {

}

func BenchmarkZapApi(b *testing.B) {
b.ResetTimer()
for i := 0; i < b.N; i++ {
handleFields("Hello ",
Uint64("world", 0),
Uint64("world", 1),
Uint64("world", 2),
)
}
b.StopTimer()
}




-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: is it possible to speed up type assertion?

[roger peppe]

On Mon, 26 Nov 2018 at 16:44,  wrote:

> Do you mean this
> // This is straight from the https://github.com/uber-go/zap plabook
> func (b *Binlog) LogStructured(msg string, fields ...Field) error
>
> My first goal was to allow drop in replacement for the  log package
> I have to handle 50K queries/s on a mediocre machine. My time budget is
> about ~200 micro/query
>

How many log messages are being produced per query? What are your queries
actually doing? What does the profiler tell you?
If logging is really a bottleneck, you could consider other approaches such
as sampling or just logging less often, or differently.

BTW if you're handling 50K queries per second, that gives you 20µs/query,
not 200 AFAICS.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: is it possible to speed up type assertion?

[larytet]

Do you mean this 
// This is straight from the https://github.com/uber-go/zap plabook
func (b *Binlog) LogStructured(msg string, fields ...Field) error

My first goal was to allow drop in replacement for the  log package
I have to handle 50K queries/s on a mediocre machine. My time budget is 
about ~200 micro/query

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: is it possible to speed up type assertion?

[roger peppe]

On Mon, 26 Nov 2018 at 14:16, Arkady  wrote:

> ZAP is significantly slower than what I do. The binary log has an inherent
> edge.


AFAIK there is nothing about zap which precludes it from writing binary
files.

Unlike zap, your scheme will inherently incur more memory allocations, as
it takes a memory allocation to put a non-pointer value into an interface
(that's the reason why zap is designed the way it is), so I suspect it will
end up slower in more realistic scenarios.

For comparison call to Log() is 3x faster than fmt.Fprintf()
>

At least fmt.Fprintf works predictably and reliably on all Go
architectures. Correctness is more important than speed. I'd suggest
starting with a more complete solution and making it work before trying to
optimise the heck out of it.

  cheers,
rog.

I have added BenchmarkSingleIntRogerPeppe() - 13ns more
> On Mon, Nov 26, 2018 at 4:09 PM roger peppe  wrote:
> >
> > On Sun, 25 Nov 2018 at 19:17,  wrote:
> >>
> >> These are great tips! Thank you!
> >> This is the context for the code above
> https://github.com/larytet/binlog/blob/master/binlog.go#L548
> >
> >
> > I took a look at this code. It seems that you have a deep understanding
> of how the runtime works, but to me it really seems like you're prematurely
> optimising here, and running serious risk of broken code. The code is full
> of unsafe and non-portable operations that will almost certainly break in
> the future. For example, reading /proc to determine the base offset for
> static strings is... inadvisable.
> >
> > Just because you know what's going on under the covers doesn't mean that
> you should write code that relies on that information.
> >
> > If you want to see a highly performant logging implementation that does
> not seriously rely on unsafe practices, I'd encourage you to take a look at
> the zap package (https://godoc.org/go.uber.org/zap).
> >
> > By the way, your SingleInt benchmark is misleading. You're using a
> constant argument to Log, which means that the runtime can use a single
> interface value for every call, with no allocation required. If you change
> the loop so that it passes a different number each time:
> >
> > for i := 0; i < b.N; i++ {
> > binlog.Log(fmtString, i)
> > }
> >
> > you are likely to find that the performance gap is considerably smaller.
> >
> >   cheers,
> > rog.
> >
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: is it possible to speed up type assertion?

[Robert Johnstone]

Hello,

Separate question, why are you passing an unsafe pointer to writer?  You 
are (probably) forcing that int to escape to the heap.  If you want to 
write an uint64, pass in a uint64.

1) I suspect that you are using pointer arithmetic inside writer, don't.  
The code will not be portable.  Instead, you should use shift and mask to 
extract the bytes (e.x, uint8(i>>16).  I expect the resulting code will be 
faster.

2)  Even if you keep the pointer arithmetic, you should defer taking the 
address until necessary.


Good luck.

Robert


On Sunday, 25 November 2018 11:10:09 UTC-5, Arkady M wrote:
>
> The code below consumes ~40% of the total execution time. According to 
> the profiler i := uint64(arg.(uint32)) is a major contributor
>
> // Cast the integer argument to uint64 and call a "writer"
> // The "writer" knows how many bytes to add to the binary stream
> // Type casts from interface{} to integer consume 40% of the overall
> // time. Can I do better? What is interface{} in Golang?
> func (b *Binlog) writeArgumentToOutput(writer writer, arg interface{}, 
> argKind reflect.Kind) error {
> // unsafe pointer to the data depends on the data type
> var err error
> switch argKind {
> case reflect.Int8:
> i := uint64(arg.(int8))
> err = writer.write(b.ioWriter, unsafe.Pointer())
> case reflect.Int16:
> i := uint64(arg.(int16))
> err = writer.write(b.ioWriter, unsafe.Pointer())
> case reflect.Int32:
> i := uint64(arg.(int32))
> err = writer.write(b.ioWriter, unsafe.Pointer())
> case reflect.Int64:
> i := uint64(arg.(int64))
> err = writer.write(b.ioWriter, unsafe.Pointer())
> case reflect.Uint8:
> i := uint64(arg.(uint8))
> err = writer.write(b.ioWriter, unsafe.Pointer())
> case reflect.Uint16:
> i := uint64(arg.(uint16))
> err = writer.write(b.ioWriter, unsafe.Pointer())
> case reflect.Uint32:
> i := uint64(arg.(uint32))
> err = writer.write(b.ioWriter, unsafe.Pointer())
> case reflect.Uint64:
> i := uint64(arg.(uint64))
> err = writer.write(b.ioWriter, unsafe.Pointer())
> case reflect.Int:
> i := uint64(arg.(int))
> err = writer.write(b.ioWriter, unsafe.Pointer())
> case reflect.Uint:
> i := uint64(arg.(uint))
> err = writer.write(b.ioWriter, unsafe.Pointer())
> default:
> return fmt.Errorf("Unsupported type: %T\n", reflect.TypeOf(arg))
> }
> return err
> }
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: is it possible to speed up type assertion?

[roger peppe]

On Sun, 25 Nov 2018 at 19:17,  wrote:

> These are great tips! Thank you!
> This is the context for the code above
> https://github.com/larytet/binlog/blob/master/binlog.go#L548
>

I took a look at this code. It seems that you have a deep understanding of
how the runtime works, but to me it really seems like you're prematurely
optimising here, and running serious risk of broken code. The code is full
of unsafe and non-portable operations that will almost certainly break in
the future. For example, reading /proc to determine the base offset for
static strings is... inadvisable.

Just because you know what's going on under the covers doesn't mean that
you should write code that relies on that information.

If you want to see a highly performant logging implementation that does not
seriously rely on unsafe practices, I'd encourage you to take a look at the
zap package (https://godoc.org/go.uber.org/zap).

By the way, your SingleInt benchmark is misleading. You're using a constant
argument to Log, which means that the runtime can use a single interface
value for every call, with no allocation required. If you change the loop
so that it passes a different number each time:

for i := 0; i < b.N; i++ {
binlog.Log(fmtString, i)
}

you are likely to find that the performance gap is considerably smaller.

  cheers,
rog.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: is it possible to speed up type assertion?

[Arkady]

Jan,

I have just measured overall performance of my code - call to Log(string, 
args []interface{}). 
This code makes the difference 

type iface struct {
tab  *unsafe.Pointer
data *unsafe.Pointer
}

func getInterfaceData(arg interface{}) unsafe.Pointer {
return unsafe.Pointer*iface)(unsafe.Pointer())).data))
}

func (b *Binlog) writeArgumentToOutput(writer writer, arg interface{}) 
error {
// unsafe pointer to the data depends on the data type
var err error
err = writer.write(b.ioWriter, getInterfaceData(arg))
return err
}



-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: is it possible to speed up type assertion?

[Jan Mercl]

> The code below consumes ~40% of the total execution time. According to
the profiler i := uint64(arg.(uint32)) is a major contributor
>
> // Cast the integer argument to uint64 and call a "writer"
> // The "writer" knows how many bytes to add to the binary stream
> // Type casts from interface{} to integer consume 40% of the overall
> // time. Can I do better? What is interface{} in Golang?
> func (b *Binlog) writeArgumentToOutput(writer writer, arg interface{},
argKind reflect.Kind) error {
> // unsafe pointer to the data depends on the data type
> var err error
> switch argKind {
> case reflect.Int8:
> i := uint64(arg.(int8))
> err = writer.write(b.ioWriter, unsafe.Pointer())
> case reflect.Int16:
> i := uint64(arg.(int16))
> err = writer.write(b.ioWriter, unsafe.Pointer())
> case reflect.Int32:
> i := uint64(arg.(int32))
> err = writer.write(b.ioWriter, unsafe.Pointer())
> case reflect.Int64:
> i := uint64(arg.(int64))
> err = writer.write(b.ioWriter, unsafe.Pointer())
> case reflect.Uint8:
> i := uint64(arg.(uint8))
> err = writer.write(b.ioWriter, unsafe.Pointer())
> case reflect.Uint16:
> i := uint64(arg.(uint16))
> err = writer.write(b.ioWriter, unsafe.Pointer())
> case reflect.Uint32:
> i := uint64(arg.(uint32))
> err = writer.write(b.ioWriter, unsafe.Pointer())
> case reflect.Uint64:
> i := uint64(arg.(uint64))
> err = writer.write(b.ioWriter, unsafe.Pointer())
> case reflect.Int:
> i := uint64(arg.(int))
> err = writer.write(b.ioWriter, unsafe.Pointer())
> case reflect.Uint:
> i := uint64(arg.(uint))
> err = writer.write(b.ioWriter, unsafe.Pointer())
> default:
> return fmt.Errorf("Unsupported type: %T\n",
reflect.TypeOf(arg))
> }
> return err
> }

What roger peppe said.

- Performing an unchecked type assertion is incorrect in the general case.

Example: https://play.golang.org/p/YmZyw0MnOK8

- Unsafe seems to be used for no good reason.

- Reflect ditto.

This code https://play.golang.org/p/4sd1yayjoNY prints

500035.3 ns/op

While this one https://play.golang.org/p/tSfWbrqv4PN prints

1   18.7 ns/op

Using Intel® Xeon(R) CPU E5-1650 v2 @ 3.50GHz × 12.

PS: The last two links point to code that cannot run in the playground.

-- 

-j

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: is it possible to speed up type assertion?

[Arkady]

P.S. shaves 20% from the total execution time.
On Mon, Nov 26, 2018 at 10:22 AM  wrote:
>
> The ugly hack below shaves 20% from the switch-case
> type iface struct {
> tab  *unsafe.Pointer
> data *unsafe.Pointer
> }
>
> func getInterfaceData(arg interface{}) unsafe.Pointer {
> return unsafe.Pointer*iface)(unsafe.Pointer())).data))
> }
>
> // Cast the integer argument to uint64 and call a "writer"
> // The "writer" knows how many bytes to add to the binary stream
> //
> // Type casts from interface{} to integer consume 40% of the overall
> // time. Can I do better? What is interface{} in Golang?
> // Switching to args *[]interface makes the performance 2x worse
> // Before you jump to conlusions see
> // https://groups.google.com/forum/#!topic/golang-nuts/Og8s9Y-Kif4
> func (b *Binlog) writeArgumentToOutput(writer writer, arg interface{}) error {
> // unsafe pointer to the data depends on the data type
> var err error
> err = writer.write(b.ioWriter, getInterfaceData(arg))
> return err
> }
>
>
> --
> You received this message because you are subscribed to a topic in the Google 
> Groups "golang-nuts" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/golang-nuts/Og8s9Y-Kif4/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: is it possible to speed up type assertion?

[larytet]

The ugly hack below shaves 20% from the switch-case
type iface struct {
tab  *unsafe.Pointer
data *unsafe.Pointer
}

func getInterfaceData(arg interface{}) unsafe.Pointer {
return unsafe.Pointer*iface)(unsafe.Pointer())).data))
}

// Cast the integer argument to uint64 and call a "writer"
// The "writer" knows how many bytes to add to the binary stream
//
// Type casts from interface{} to integer consume 40% of the overall
// time. Can I do better? What is interface{} in Golang?
// Switching to args *[]interface makes the performance 2x worse
// Before you jump to conlusions see
// https://groups.google.com/forum/#!topic/golang-nuts/Og8s9Y-Kif4
func (b *Binlog) writeArgumentToOutput(writer writer, arg interface{}) 
error {
// unsafe pointer to the data depends on the data type
var err error
err = writer.write(b.ioWriter, getInterfaceData(arg))
return err
}


-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: is it possible to speed up type assertion?

[Space A.]

+1000
The most valuable comment in this thread IMO. Thank you.


четверг, 2 февраля 2017 г., 13:41:25 UTC+3 пользователь Axel Wagner написал:
>
> I want to re-emphasize that all of these are micro-benchmarks. They say 
> nothing useful at all, as proven by this thread; in some circumstances, the 
> added cost may be significant, in others it isn't. The same rule that has 
> been repeated lots of times on this list still applies: Write your program 
> to be simple and readable, *if* it is too slow, benchmark and improve.​ 
> Basing your code on what any of these Benchmarks says is just ridiculous, 
> base it on the bottlenecks you measure in your actual, real-world program 
> running on the actual production hardware with actual production data.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: is it possible to speed up type assertion?

[larytet]

This code is ~20% slower (probably)
func (b *Binlog) writeArgumentToOutput(writer writer, arg interface{}) 
error {
var err error
rv := reflect.ValueOf(arg)
var v uint64
if k := rv.Kind(); k >= reflect.Int && k < reflect.Uint {
v = uint64(rv.Int())
err = writer.write(b.ioWriter, unsafe.Pointer())
} else if k <= reflect.Uintptr {
v = rv.Uint()
err = writer.write(b.ioWriter, unsafe.Pointer())
} else {
return fmt.Errorf("Unsupported type: %T\n", reflect.TypeOf(arg))
}
/* write v */
return err
}


-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: is it possible to speed up type assertion?

[larytet]

This code fails my tests with "panic: interface conversion: interface {} is 
int32, not int"

switch argKind {
case reflect.Int, reflect.Int8, reflect.Int16, reflect.Int32, reflect.
Int64:
i := uint64(arg.(int))
err = writer.write(b.ioWriter, unsafe.Pointer())
case reflect.Uint, reflect.Uint8, reflect.Uint16, reflect.Uint32, 
reflect.Uint64:
i := arg.(uint)
err = writer.write(b.ioWriter, unsafe.Pointer())
default:
return fmt.Errorf("Unsupported type: %T\n", reflect.TypeOf(arg))
}




-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: is it possible to speed up type assertion?

[larytet]

These are great tips! Thank you! 
This is the context for the code above 
https://github.com/larytet/binlog/blob/master/binlog.go#L548
The following switch has exactly the same performance

switch arg := arg.(type) {
case int:
i := uint64(arg)
err = writer.write(b.ioWriter, unsafe.Pointer())
case uint:



-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: is it possible to speed up type assertion?

[roger peppe]

On Sun, 25 Nov 2018 at 18:25, Ian Denhardt  wrote:

> Quoting roger peppe (2018-11-25 12:01:08)
> >On Sun, 25 Nov 2018 at 16:54, 'Axel Wagner' via golang-nuts
> ><[1]golang-nuts@googlegroups.com> wrote:
> >
> >I'd suggest simply
> >func (b *Binlog) writeArgumentToOutput(writer writer, arg uint64)
> error
> >{ /* do the writing */ }
> >and doing the actual conversions at the call-site. It's type-safe,
> >shorter, faster and more idiomatic - with the tiny downside of a
> >`uint64()` here and there.
> >Alternatively, use reflect as it's intended to - something like
> >func� writeArgumentToOutput(writer writer, arg interface{}) error {
> >�  �  rv := reflect.ValueOf(arg)
> >�  �  var v uint64
> >�  �  if k := rv.Kind(); k >= reflect.Int && k < reflect.Uint {
> >
> >I know constants are protected by the Go compatibility guarantee,
> doing
> >range comparisons on reflect.Kind constants seems a bit dubious to me.
> >Without going to the definitions, it's not clear to the reader which
> >exact kinds are included here. I'd suggest enumerating all the
> expected
> >kinds directly in a switch statement (the compiler may well optimize
> to
> >a range comparison for that anyway).
>
> I agree; had to stare at this a bit. Something like:
>
> switch rv.Kind() {
> case reflect.Int, reflect.Int8, reflect.Int16, reflect.Int32,
> reflect.Int64:
> v = uint64(rv.Int())
> case reflect.Uint, reflect.Uint8, reflect.Uint16, reflect.Uint32,
> reflect.Uint64:
> v = rv.Uint()
> default:
> return fmt.Errorf("Unsupported type: %T\n", reflect.TypeOf(arg))
> }
>

Yes - I linked to some very similar play.golang.org code in my first reply
in this thread.

I wonder whether reflect.Type should have "CanInt", and "CanUint" methods
that can be called to determine whether it's OK to call Value.Int and
Value.Uint respectively, without needing to explicitly enumerate all the
int-like types.

Only slightly more verbose, but much easier to understand. But ultimate
> Axel's first instinct is I think the right one -- just do the cast at
> the call site.
>

Agreed, but this might not be possible if the value has come from within
some other type using reflect.


> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: is it possible to speed up type assertion?

[Ian Denhardt]

Quoting roger peppe (2018-11-25 12:01:08)
>On Sun, 25 Nov 2018 at 16:54, 'Axel Wagner' via golang-nuts
><[1]golang-nuts@googlegroups.com> wrote:
>
>I'd suggest simply
>func (b *Binlog) writeArgumentToOutput(writer writer, arg uint64) error
>{ /* do the writing */ }
>and doing the actual conversions at the call-site. It's type-safe,
>shorter, faster and more idiomatic - with the tiny downside of a
>`uint64()` here and there.
>Alternatively, use reflect as it's intended to - something like
>func� writeArgumentToOutput(writer writer, arg interface{}) error {
>�  �  rv := reflect.ValueOf(arg)
>�  �  var v uint64
>�  �  if k := rv.Kind(); k >= reflect.Int && k < reflect.Uint {
>
>I know constants are protected by the Go compatibility guarantee, doing
>range comparisons on reflect.Kind constants seems a bit dubious to me.
>Without going to the definitions, it's not clear to the reader which
>exact kinds are included here. I'd suggest enumerating all the expected
>kinds directly in a switch statement (the compiler may well optimize to
>a range comparison for that anyway).

I agree; had to stare at this a bit. Something like:

switch rv.Kind() {
case reflect.Int, reflect.Int8, reflect.Int16, reflect.Int32, reflect.Int64:
v = uint64(rv.Int())
case reflect.Uint, reflect.Uint8, reflect.Uint16, reflect.Uint32, 
reflect.Uint64:
v = rv.Uint()
default:
return fmt.Errorf("Unsupported type: %T\n", reflect.TypeOf(arg))
}

Only slightly more verbose, but much easier to understand. But ultimate
Axel's first instinct is I think the right one -- just do the cast at
the call site.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: is it possible to speed up type assertion?

[roger peppe]

On Sun, 25 Nov 2018 at 16:54, 'Axel Wagner' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> I'd suggest simply
> func (b *Binlog) writeArgumentToOutput(writer writer, arg uint64) error {
> /* do the writing */ }
> and doing the actual conversions at the call-site. It's type-safe,
> shorter, faster and more idiomatic - with the tiny downside of a `uint64()`
> here and there.
>
> Alternatively, use reflect as it's intended to - something like
> func writeArgumentToOutput(writer writer, arg interface{}) error {
> rv := reflect.ValueOf(arg)
> var v uint64
> if k := rv.Kind(); k >= reflect.Int && k < reflect.Uint {
>

I know constants are protected by the Go compatibility guarantee, doing
range comparisons on reflect.Kind constants seems a bit dubious to me.
Without going to the definitions, it's not clear to the reader which exact
kinds are included here. I'd suggest enumerating all the expected kinds
directly in a switch statement (the compiler may well optimize to a range
comparison for that anyway).

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: is it possible to speed up type assertion?

[roger peppe]

You don't need to use reflect here. You may well find that something like
this is faster:

func (b *Binlog) writeArgumentToOutput(writer writer, arg
interface{}) error {
var i uint64
switch arg := arg.(type) {
case uintptr:
i = uint64(arg)
case int:
i = uint64(arg)
case int8:
i = uint64(arg)
case int16:
i = uint64(arg)
case int32:
i = uint64(arg)
case int64:
i = uint64(arg)
case uint8:
i = uint64(arg)
case uint16:
i = uint64(arg)
case uint32:
i = uint64(arg)
case uint64:
i = arg
default:
return fmt.Errorf("Unsupported type: %T\n",
reflect.TypeOf(arg))
}
return writer.write(b.ioWriter, )
}

There are a couple of issues I'd point out with the original code:
- just because a value has a given Kind (e.g. reflect.Int16) does not mean
it can be converted to that type, because it may be some other named type
with an int16 underlying type. A better (and shorter, but probably no
faster) way to do it would be something like:
https://play.golang.org/p/jhpbaaDoY57
- it seems odd that you're passing an unsafe.Pointer to the write method.
How is that method supposed to know how many bytes to write?



On Sun, 25 Nov 2018 at 16:09,  wrote:

> The code below consumes ~40% of the total execution time. According to
> the profiler i := uint64(arg.(uint32)) is a major contributor
>
> // Cast the integer argument to uint64 and call a "writer"
> // The "writer" knows how many bytes to add to the binary stream
> // Type casts from interface{} to integer consume 40% of the overall
> // time. Can I do better? What is interface{} in Golang?
> func (b *Binlog) writeArgumentToOutput(writer writer, arg interface{},
> argKind reflect.Kind) error {
> // unsafe pointer to the data depends on the data type
> var err error
> switch argKind {
> case reflect.Int8:
> i := uint64(arg.(int8))
> err = writer.write(b.ioWriter, unsafe.Pointer())
> case reflect.Int16:
> i := uint64(arg.(int16))
> err = writer.write(b.ioWriter, unsafe.Pointer())
> case reflect.Int32:
> i := uint64(arg.(int32))
> err = writer.write(b.ioWriter, unsafe.Pointer())
> case reflect.Int64:
> i := uint64(arg.(int64))
> err = writer.write(b.ioWriter, unsafe.Pointer())
> case reflect.Uint8:
> i := uint64(arg.(uint8))
> err = writer.write(b.ioWriter, unsafe.Pointer())
> case reflect.Uint16:
> i := uint64(arg.(uint16))
> err = writer.write(b.ioWriter, unsafe.Pointer())
> case reflect.Uint32:
> i := uint64(arg.(uint32))
> err = writer.write(b.ioWriter, unsafe.Pointer())
> case reflect.Uint64:
> i := uint64(arg.(uint64))
> err = writer.write(b.ioWriter, unsafe.Pointer())
> case reflect.Int:
> i := uint64(arg.(int))
> err = writer.write(b.ioWriter, unsafe.Pointer())
> case reflect.Uint:
> i := uint64(arg.(uint))
> err = writer.write(b.ioWriter, unsafe.Pointer())
> default:
> return fmt.Errorf("Unsupported type: %T\n", reflect.TypeOf(arg))
> }
> return err
> }
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: is it possible to speed up type assertion?

['Axel Wagner' via golang-nuts]

I'd suggest simply
func (b *Binlog) writeArgumentToOutput(writer writer, arg uint64) error {
/* do the writing */ }
and doing the actual conversions at the call-site. It's type-safe, shorter,
faster and more idiomatic - with the tiny downside of a `uint64()` here and
there.

Alternatively, use reflect as it's intended to - something like
func writeArgumentToOutput(writer writer, arg interface{}) error {
rv := reflect.ValueOf(arg)
var v uint64
if k := rv.Kind(); k >= reflect.Int && k < reflect.Uint {
v = uint64(rv.Int())
} else if k <= reflect.Uintptr {
v = rv.Uint()
} else {
return fmt.Errorf("Unsupported type: %T\n", reflect.TypeOf(arg))
}
/* write v */
return nil
}

this is probably a bit slower than the above, type-safe version, but
probably not noticeably slower than the unsafe large type-switch above and
has the benefit of also not needing conversion at the call-site (it also
works correctly with all integer types, which the type-switch doesn't).

But in the end, any slowness here comes from passing things as an
interface{}, instead of just as a value. You can't really optimize that
away, because it's inherent in the approach.

On Sun, Nov 25, 2018 at 5:32 PM Michel Levieux 
wrote:

> No offense intended, but that code is wrong on so many levels...
>
>
> I strongly believe you that you are not trying to offend anyone, but this
> question is interesting for me too, and I'd like more details. Could you
> please explain, from worst to "less worst", what's wrong with this code?
> Reflection is sometimes really misleading for people who don't have a deep
> understanding of the compiler, and such pieces of code exist all around the
> internet. Would you give us a more precise feedback?
>
> Thanks in advance!
>
> Le dim. 25 nov. 2018 à 17:17, Jan Mercl <0xj...@gmail.com> a écrit :
>
>> No offense intended, but that code is wrong on so many levels...
>>
>> On Sun, Nov 25, 2018, 17:10  wrote:
>>
>>> The code below consumes ~40% of the total execution time. According to
>>> the profiler i := uint64(arg.(uint32)) is a major contributor
>>>
>>> // Cast the integer argument to uint64 and call a "writer"
>>> // The "writer" knows how many bytes to add to the binary stream
>>> // Type casts from interface{} to integer consume 40% of the overall
>>> // time. Can I do better? What is interface{} in Golang?
>>> func (b *Binlog) writeArgumentToOutput(writer writer, arg interface{},
>>> argKind reflect.Kind) error {
>>> // unsafe pointer to the data depends on the data type
>>> var err error
>>> switch argKind {
>>> case reflect.Int8:
>>> i := uint64(arg.(int8))
>>> err = writer.write(b.ioWriter, unsafe.Pointer())
>>> case reflect.Int16:
>>> i := uint64(arg.(int16))
>>> err = writer.write(b.ioWriter, unsafe.Pointer())
>>> case reflect.Int32:
>>> i := uint64(arg.(int32))
>>> err = writer.write(b.ioWriter, unsafe.Pointer())
>>> case reflect.Int64:
>>> i := uint64(arg.(int64))
>>> err = writer.write(b.ioWriter, unsafe.Pointer())
>>> case reflect.Uint8:
>>> i := uint64(arg.(uint8))
>>> err = writer.write(b.ioWriter, unsafe.Pointer())
>>> case reflect.Uint16:
>>> i := uint64(arg.(uint16))
>>> err = writer.write(b.ioWriter, unsafe.Pointer())
>>> case reflect.Uint32:
>>> i := uint64(arg.(uint32))
>>> err = writer.write(b.ioWriter, unsafe.Pointer())
>>> case reflect.Uint64:
>>> i := uint64(arg.(uint64))
>>> err = writer.write(b.ioWriter, unsafe.Pointer())
>>> case reflect.Int:
>>> i := uint64(arg.(int))
>>> err = writer.write(b.ioWriter, unsafe.Pointer())
>>> case reflect.Uint:
>>> i := uint64(arg.(uint))
>>> err = writer.write(b.ioWriter, unsafe.Pointer())
>>> default:
>>> return fmt.Errorf("Unsupported type: %T\n", reflect.TypeOf(arg))
>>> }
>>> return err
>>> }
>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to golang-nuts+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
>>
>> -j
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-nuts+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to 

Re: [go-nuts] Re: is it possible to speed up type assertion?

[Michel Levieux]

>
> No offense intended, but that code is wrong on so many levels...


I strongly believe you that you are not trying to offend anyone, but this
question is interesting for me too, and I'd like more details. Could you
please explain, from worst to "less worst", what's wrong with this code?
Reflection is sometimes really misleading for people who don't have a deep
understanding of the compiler, and such pieces of code exist all around the
internet. Would you give us a more precise feedback?

Thanks in advance!

Le dim. 25 nov. 2018 à 17:17, Jan Mercl <0xj...@gmail.com> a écrit :

> No offense intended, but that code is wrong on so many levels...
>
> On Sun, Nov 25, 2018, 17:10  wrote:
>
>> The code below consumes ~40% of the total execution time. According to
>> the profiler i := uint64(arg.(uint32)) is a major contributor
>>
>> // Cast the integer argument to uint64 and call a "writer"
>> // The "writer" knows how many bytes to add to the binary stream
>> // Type casts from interface{} to integer consume 40% of the overall
>> // time. Can I do better? What is interface{} in Golang?
>> func (b *Binlog) writeArgumentToOutput(writer writer, arg interface{},
>> argKind reflect.Kind) error {
>> // unsafe pointer to the data depends on the data type
>> var err error
>> switch argKind {
>> case reflect.Int8:
>> i := uint64(arg.(int8))
>> err = writer.write(b.ioWriter, unsafe.Pointer())
>> case reflect.Int16:
>> i := uint64(arg.(int16))
>> err = writer.write(b.ioWriter, unsafe.Pointer())
>> case reflect.Int32:
>> i := uint64(arg.(int32))
>> err = writer.write(b.ioWriter, unsafe.Pointer())
>> case reflect.Int64:
>> i := uint64(arg.(int64))
>> err = writer.write(b.ioWriter, unsafe.Pointer())
>> case reflect.Uint8:
>> i := uint64(arg.(uint8))
>> err = writer.write(b.ioWriter, unsafe.Pointer())
>> case reflect.Uint16:
>> i := uint64(arg.(uint16))
>> err = writer.write(b.ioWriter, unsafe.Pointer())
>> case reflect.Uint32:
>> i := uint64(arg.(uint32))
>> err = writer.write(b.ioWriter, unsafe.Pointer())
>> case reflect.Uint64:
>> i := uint64(arg.(uint64))
>> err = writer.write(b.ioWriter, unsafe.Pointer())
>> case reflect.Int:
>> i := uint64(arg.(int))
>> err = writer.write(b.ioWriter, unsafe.Pointer())
>> case reflect.Uint:
>> i := uint64(arg.(uint))
>> err = writer.write(b.ioWriter, unsafe.Pointer())
>> default:
>> return fmt.Errorf("Unsupported type: %T\n", reflect.TypeOf(arg))
>> }
>> return err
>> }
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-nuts+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
>
> -j
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: is it possible to speed up type assertion?

[Jan Mercl]

No offense intended, but that code is wrong on so many levels...

On Sun, Nov 25, 2018, 17:10  wrote:

> The code below consumes ~40% of the total execution time. According to
> the profiler i := uint64(arg.(uint32)) is a major contributor
>
> // Cast the integer argument to uint64 and call a "writer"
> // The "writer" knows how many bytes to add to the binary stream
> // Type casts from interface{} to integer consume 40% of the overall
> // time. Can I do better? What is interface{} in Golang?
> func (b *Binlog) writeArgumentToOutput(writer writer, arg interface{},
> argKind reflect.Kind) error {
> // unsafe pointer to the data depends on the data type
> var err error
> switch argKind {
> case reflect.Int8:
> i := uint64(arg.(int8))
> err = writer.write(b.ioWriter, unsafe.Pointer())
> case reflect.Int16:
> i := uint64(arg.(int16))
> err = writer.write(b.ioWriter, unsafe.Pointer())
> case reflect.Int32:
> i := uint64(arg.(int32))
> err = writer.write(b.ioWriter, unsafe.Pointer())
> case reflect.Int64:
> i := uint64(arg.(int64))
> err = writer.write(b.ioWriter, unsafe.Pointer())
> case reflect.Uint8:
> i := uint64(arg.(uint8))
> err = writer.write(b.ioWriter, unsafe.Pointer())
> case reflect.Uint16:
> i := uint64(arg.(uint16))
> err = writer.write(b.ioWriter, unsafe.Pointer())
> case reflect.Uint32:
> i := uint64(arg.(uint32))
> err = writer.write(b.ioWriter, unsafe.Pointer())
> case reflect.Uint64:
> i := uint64(arg.(uint64))
> err = writer.write(b.ioWriter, unsafe.Pointer())
> case reflect.Int:
> i := uint64(arg.(int))
> err = writer.write(b.ioWriter, unsafe.Pointer())
> case reflect.Uint:
> i := uint64(arg.(uint))
> err = writer.write(b.ioWriter, unsafe.Pointer())
> default:
> return fmt.Errorf("Unsupported type: %T\n", reflect.TypeOf(arg))
> }
> return err
> }
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
-- 

-j

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: is it possible to speed up type assertion?

[larytet]

The code below consumes ~40% of the total execution time. According to the 
profiler i := uint64(arg.(uint32)) is a major contributor

// Cast the integer argument to uint64 and call a "writer"
// The "writer" knows how many bytes to add to the binary stream
// Type casts from interface{} to integer consume 40% of the overall
// time. Can I do better? What is interface{} in Golang?
func (b *Binlog) writeArgumentToOutput(writer writer, arg interface{}, 
argKind reflect.Kind) error {
// unsafe pointer to the data depends on the data type
var err error
switch argKind {
case reflect.Int8:
i := uint64(arg.(int8))
err = writer.write(b.ioWriter, unsafe.Pointer())
case reflect.Int16:
i := uint64(arg.(int16))
err = writer.write(b.ioWriter, unsafe.Pointer())
case reflect.Int32:
i := uint64(arg.(int32))
err = writer.write(b.ioWriter, unsafe.Pointer())
case reflect.Int64:
i := uint64(arg.(int64))
err = writer.write(b.ioWriter, unsafe.Pointer())
case reflect.Uint8:
i := uint64(arg.(uint8))
err = writer.write(b.ioWriter, unsafe.Pointer())
case reflect.Uint16:
i := uint64(arg.(uint16))
err = writer.write(b.ioWriter, unsafe.Pointer())
case reflect.Uint32:
i := uint64(arg.(uint32))
err = writer.write(b.ioWriter, unsafe.Pointer())
case reflect.Uint64:
i := uint64(arg.(uint64))
err = writer.write(b.ioWriter, unsafe.Pointer())
case reflect.Int:
i := uint64(arg.(int))
err = writer.write(b.ioWriter, unsafe.Pointer())
case reflect.Uint:
i := uint64(arg.(uint))
err = writer.write(b.ioWriter, unsafe.Pointer())
default:
return fmt.Errorf("Unsupported type: %T\n", reflect.TypeOf(arg))
}
return err
}


-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: is it possible to speed up type assertion?

[Michael Jones]

Nothing wrong with micro benchmarks. Sorry if I gave that impression. The
problem is in trying to use them to anticipate behavior of a larger system.
If you have a "micro question" then a "micro benchmark" is a great one.
Most people have macro questions though, and yet they often start with
micro benchmarks as a logical-seeming computer science version of Descartes
method of reasoning. The problem is that in the computer case, it can be
difficult or impossible to extrapolate and deduce behavior at larger scales.

Performance is always a good thing. But other things are good too, and even
performance comes in flavors. Note benchmarks that report number of
allocations and size of allocations as well as elapsed time. There are
macro cases where slower-with-less-garbage might lead to a faster overall
run time than faster-with-more-GC-pressure. A macro benchmark answers this;
a micro one does not.

This is also a subtle strategic issue in performance tuning. If you make
type assertions faster but defers slower, is that better for the language?
There is no answer for this. No real answer. Because it would be better for
some people and worse for others. Even the Go Gods don't know answers to
such questions with confidence.

Agree about benchmarking everything. Agree about tracking things seen as
slow. Absolutely agree about exposing the cost of actions, and personally,
like designs where most things have uniform cost--where the textual
complexity of the program makes the runtime complexity evident--except for
well marked danger zones.

Where I'm less in agreement is about "...showing the gap for Go to catch
up." This can be good, but not always. If language X is 10x faster at some
small thing, but that is at the expense of memory usage, GC pressure,
complicated dynamic library settings, absence of concurrency architecture,
etc., then it is important to understand that the micro decision is made
with appreciation of macro decisions. When all can be better then it must.
But often engineering is about choosing wise tradeoffs and that's the risk
of inspecting too closely.

On Thu, Feb 2, 2017 at 4:36 PM, Chris Lu  wrote:

> Thanks for the detailed thoughtful answer!
>
> Statistically you are correct. 95% of Go features are reasonably fast, and
> will get 99% job done very fast. But can we call the benchmark on the rest
> 5% slow part micro benchmarking?
>
> This can easily become an objective discussion based on different
> experiences. We can get 99% people supporting that this is a micro
> benchmarking. However that would not help anything. Indeed this seems an
> ostrich approach.
>
> We are talking about Go language here, not any specific application. A
> fair benchmark can be measuring differences against other languages,
> showing the gap for Go to catch up.
>
> Anything we feel slow should be tracked so that we can see the performance
> improvement over time and newbies can have a correct expectation of the
> cost.
>
> Chris
>
>
> On Thu, Feb 2, 2017 at 3:26 PM, Michael Jones 
> wrote:
>
>> Insight here feels tenuous.
>>
>> It is rare that a well-written "real" program would be measurably
>> influenced by something this small. As it happens, I often write such rare
>> programs (where a 2x faster math.Log() really might make the whole program
>> run 1.9x faster). Even as a poster child for it, I think it is very
>> uncommon. To get here you can never read or write data, transcode data,
>> communicate with devices, processes, or users, or do anything else so
>> typical of real programs.
>>
>> Benchmarks that measure one single thing in the absence of everything
>> else are often misleading. They hide the effect of the "rest of the time"
>> as outlined above and worse, they are immune to the good and bad of the
>> reality of real computers. For example, integer divide is slow, but is also
>> often infrequent. If you do such a divide every 100 cycles, the nature of
>> modern CPUs is that the delay will be hidden in overlapped execution of the
>> instruction stream and at worst, other instruction streams. A nothing but
>> integer divide micro benchmark will block on the 19-cycle or whatever
>> completion rate. That's the good. On the other hand, a "write over and over
>> to the same memory" micro benchmark will run fast  thanks to multiple
>> layers of caching while the same thing on a real-program scale will have
>> cache contention effects that could be 1/20th the throughput. (This is the
>> same as measuring highway drive time at 3am vs 8am.)
>>
>> The most meaningful benchmark measures a real use case. In this situation
>> the resulting measurements directly interpret application performance. In
>> any synthetic benchmark, however, you can often be unsure how to apply the
>> result to the real world. The smaller and more focused the benchmark, the
>> less easy it is to learn from the result.
>>
>> Even simple statistical inference is subtly difficult; consider the 

Re: [go-nuts] Re: is it possible to speed up type assertion?

[Chris Lu]

Thanks for the detailed thoughtful answer!

Statistically you are correct. 95% of Go features are reasonably fast, and
will get 99% job done very fast. But can we call the benchmark on the rest
5% slow part micro benchmarking?

This can easily become an objective discussion based on different
experiences. We can get 99% people supporting that this is a micro
benchmarking. However that would not help anything. Indeed this seems an
ostrich approach.

We are talking about Go language here, not any specific application. A fair
benchmark can be measuring differences against other languages, showing the
gap for Go to catch up.

Anything we feel slow should be tracked so that we can see the performance
improvement over time and newbies can have a correct expectation of the
cost.

Chris


On Thu, Feb 2, 2017 at 3:26 PM, Michael Jones 
wrote:

> Insight here feels tenuous.
>
> It is rare that a well-written "real" program would be measurably
> influenced by something this small. As it happens, I often write such rare
> programs (where a 2x faster math.Log() really might make the whole program
> run 1.9x faster). Even as a poster child for it, I think it is very
> uncommon. To get here you can never read or write data, transcode data,
> communicate with devices, processes, or users, or do anything else so
> typical of real programs.
>
> Benchmarks that measure one single thing in the absence of everything else
> are often misleading. They hide the effect of the "rest of the time" as
> outlined above and worse, they are immune to the good and bad of the
> reality of real computers. For example, integer divide is slow, but is also
> often infrequent. If you do such a divide every 100 cycles, the nature of
> modern CPUs is that the delay will be hidden in overlapped execution of the
> instruction stream and at worst, other instruction streams. A nothing but
> integer divide micro benchmark will block on the 19-cycle or whatever
> completion rate. That's the good. On the other hand, a "write over and over
> to the same memory" micro benchmark will run fast  thanks to multiple
> layers of caching while the same thing on a real-program scale will have
> cache contention effects that could be 1/20th the throughput. (This is the
> same as measuring highway drive time at 3am vs 8am.)
>
> The most meaningful benchmark measures a real use case. In this situation
> the resulting measurements directly interpret application performance. In
> any synthetic benchmark, however, you can often be unsure how to apply the
> result to the real world. The smaller and more focused the benchmark, the
> less easy it is to learn from the result.
>
> Even simple statistical inference is subtly difficult; consider the fact
> that the average person has less than two legs. If this is hard for people,
> then how much harder to properly understand the whole-program meaning of a
> 10x slowdown in type assertions?
>
> Michael
>
> On Thu, Feb 2, 2017 at 1:55 PM, Chris Lu  wrote:
>
>> Cool! Upgrading to 1.8.rc3 shows great improvement! I wish all problems
>> can be resolved by upgrading. :) Here is the before and after result.
>>
>> chris$ go test -bench=.
>> testing: warning: no tests to run
>> BenchmarkAssertion-8 2 9.57 ns/op
>> BenchmarkAssertionOK-8   2 9.02 ns/op
>> BenchmarkBare-8   10 2.09 ns/op
>> BenchmarkIface-8 500027.0 ns/op
>> BenchmarkReflect-8   2 9.00 ns/op
>> PASS
>> ok   _/Users/chris/tmp/test 11.980s
>>
>> chris$ go version
>> go version go1.8rc3 darwin/amd64
>>
>> chris$ go test -bench=.
>> BenchmarkAssertion-8 10 2.67 ns/op
>> BenchmarkAssertionOK-8   10 2.32 ns/op
>> BenchmarkBare-8   10 2.10 ns/op
>> BenchmarkIface-8 500026.0 ns/op
>> BenchmarkReflect-8   2 8.80 ns/op
>> PASS
>> ok   _/Users/chris/tmp/test 11.761s
>>
>>
>> The time taken of the original type casting code shrinks from 8 seconds
>> to 474ms!
>>
>> count=1073741824 time taken=474.843325ms
>> count=1073741824 time taken=308.870452ms
>>
>>
>> On Thu, Feb 2, 2017 at 1:31 PM, Ian Lance Taylor  wrote:
>>
>>> On Thu, Feb 2, 2017 at 1:04 PM, Chris Lu  wrote:
>>> >
>>> > I am trying to build a generic distributed map reduce system similar to
>>> > Spark. Without generics, the APIs pass data via interface{}. For
>>> example, a
>>> > reducer is written this way:
>>> >
>>> > func sum(x, y interface{}) (interface{}, error) {
>>> >
>>> > return x.(uint64) + y.(uint64), nil
>>> >
>>> > }
>>> >
>>> >
>>> > To be more generic, this framework also support LuaJIT.
>>> >
>>> > There is a noticeable difference in terms of performance difference.
>>> LuaJIT
>>> > is faster than pure Go. The profiling of pure Go showed the assertE2T
>>> and
>>> > assertI2T cost a non-trivial amount of time.
>>>
>>> Note 

Re: [go-nuts] Re: is it possible to speed up type assertion?

[Michael Jones]

Insight here feels tenuous.

It is rare that a well-written "real" program would be measurably
influenced by something this small. As it happens, I often write such rare
programs (where a 2x faster math.Log() really might make the whole program
run 1.9x faster). Even as a poster child for it, I think it is very
uncommon. To get here you can never read or write data, transcode data,
communicate with devices, processes, or users, or do anything else so
typical of real programs.

Benchmarks that measure one single thing in the absence of everything else
are often misleading. They hide the effect of the "rest of the time" as
outlined above and worse, they are immune to the good and bad of the
reality of real computers. For example, integer divide is slow, but is also
often infrequent. If you do such a divide every 100 cycles, the nature of
modern CPUs is that the delay will be hidden in overlapped execution of the
instruction stream and at worst, other instruction streams. A nothing but
integer divide micro benchmark will block on the 19-cycle or whatever
completion rate. That's the good. On the other hand, a "write over and over
to the same memory" micro benchmark will run fast  thanks to multiple
layers of caching while the same thing on a real-program scale will have
cache contention effects that could be 1/20th the throughput. (This is the
same as measuring highway drive time at 3am vs 8am.)

The most meaningful benchmark measures a real use case. In this situation
the resulting measurements directly interpret application performance. In
any synthetic benchmark, however, you can often be unsure how to apply the
result to the real world. The smaller and more focused the benchmark, the
less easy it is to learn from the result.

Even simple statistical inference is subtly difficult; consider the fact
that the average person has less than two legs. If this is hard for people,
then how much harder to properly understand the whole-program meaning of a
10x slowdown in type assertions?

Michael

On Thu, Feb 2, 2017 at 1:55 PM, Chris Lu  wrote:

> Cool! Upgrading to 1.8.rc3 shows great improvement! I wish all problems
> can be resolved by upgrading. :) Here is the before and after result.
>
> chris$ go test -bench=.
> testing: warning: no tests to run
> BenchmarkAssertion-8 2 9.57 ns/op
> BenchmarkAssertionOK-8   2 9.02 ns/op
> BenchmarkBare-8   10 2.09 ns/op
> BenchmarkIface-8 500027.0 ns/op
> BenchmarkReflect-8   2 9.00 ns/op
> PASS
> ok   _/Users/chris/tmp/test 11.980s
>
> chris$ go version
> go version go1.8rc3 darwin/amd64
>
> chris$ go test -bench=.
> BenchmarkAssertion-8 10 2.67 ns/op
> BenchmarkAssertionOK-8   10 2.32 ns/op
> BenchmarkBare-8   10 2.10 ns/op
> BenchmarkIface-8 500026.0 ns/op
> BenchmarkReflect-8   2 8.80 ns/op
> PASS
> ok   _/Users/chris/tmp/test 11.761s
>
>
> The time taken of the original type casting code shrinks from 8 seconds to
> 474ms!
>
> count=1073741824 time taken=474.843325ms
> count=1073741824 time taken=308.870452ms
>
>
> On Thu, Feb 2, 2017 at 1:31 PM, Ian Lance Taylor  wrote:
>
>> On Thu, Feb 2, 2017 at 1:04 PM, Chris Lu  wrote:
>> >
>> > I am trying to build a generic distributed map reduce system similar to
>> > Spark. Without generics, the APIs pass data via interface{}. For
>> example, a
>> > reducer is written this way:
>> >
>> > func sum(x, y interface{}) (interface{}, error) {
>> >
>> > return x.(uint64) + y.(uint64), nil
>> >
>> > }
>> >
>> >
>> > To be more generic, this framework also support LuaJIT.
>> >
>> > There is a noticeable difference in terms of performance difference.
>> LuaJIT
>> > is faster than pure Go. The profiling of pure Go showed the assertE2T
>> and
>> > assertI2T cost a non-trivial amount of time.
>>
>> Note that in the 1.8 release assertE2T and assertI2T no longer exist.
>> They were removed by https://golang.org/cl/32313.  That should speed
>> up these cases; assertE2T and assertI2T were trivial, but in some
>> cases they did call typedmemmove.  When your interface values store
>> non-pointers, and the code is inlined as it is in 1.8, the calls to
>> typedmemmove disappear.
>>
>> You might want to retry your benchmarks with the 1.8 release candidate
>> to see if you can observe any real difference.
>>
>> Ian
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Michael T. Jones
michael.jo...@gmail.com

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 

Re: [go-nuts] Re: is it possible to speed up type assertion?

[Chris Lu]

Cool! Upgrading to 1.8.rc3 shows great improvement! I wish all problems can
be resolved by upgrading. :) Here is the before and after result.

chris$ go test -bench=.
testing: warning: no tests to run
BenchmarkAssertion-8 2 9.57 ns/op
BenchmarkAssertionOK-8   2 9.02 ns/op
BenchmarkBare-8   10 2.09 ns/op
BenchmarkIface-8 500027.0 ns/op
BenchmarkReflect-8   2 9.00 ns/op
PASS
ok   _/Users/chris/tmp/test 11.980s

chris$ go version
go version go1.8rc3 darwin/amd64

chris$ go test -bench=.
BenchmarkAssertion-8 10 2.67 ns/op
BenchmarkAssertionOK-8   10 2.32 ns/op
BenchmarkBare-8   10 2.10 ns/op
BenchmarkIface-8 500026.0 ns/op
BenchmarkReflect-8   2 8.80 ns/op
PASS
ok   _/Users/chris/tmp/test 11.761s


The time taken of the original type casting code shrinks from 8 seconds to
474ms!

count=1073741824 time taken=474.843325ms
count=1073741824 time taken=308.870452ms


On Thu, Feb 2, 2017 at 1:31 PM, Ian Lance Taylor  wrote:

> On Thu, Feb 2, 2017 at 1:04 PM, Chris Lu  wrote:
> >
> > I am trying to build a generic distributed map reduce system similar to
> > Spark. Without generics, the APIs pass data via interface{}. For
> example, a
> > reducer is written this way:
> >
> > func sum(x, y interface{}) (interface{}, error) {
> >
> > return x.(uint64) + y.(uint64), nil
> >
> > }
> >
> >
> > To be more generic, this framework also support LuaJIT.
> >
> > There is a noticeable difference in terms of performance difference.
> LuaJIT
> > is faster than pure Go. The profiling of pure Go showed the assertE2T and
> > assertI2T cost a non-trivial amount of time.
>
> Note that in the 1.8 release assertE2T and assertI2T no longer exist.
> They were removed by https://golang.org/cl/32313.  That should speed
> up these cases; assertE2T and assertI2T were trivial, but in some
> cases they did call typedmemmove.  When your interface values store
> non-pointers, and the code is inlined as it is in 1.8, the calls to
> typedmemmove disappear.
>
> You might want to retry your benchmarks with the 1.8 release candidate
> to see if you can observe any real difference.
>
> Ian
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: is it possible to speed up type assertion?

[Ian Lance Taylor]

On Thu, Feb 2, 2017 at 1:04 PM, Chris Lu  wrote:
>
> I am trying to build a generic distributed map reduce system similar to
> Spark. Without generics, the APIs pass data via interface{}. For example, a
> reducer is written this way:
>
> func sum(x, y interface{}) (interface{}, error) {
>
> return x.(uint64) + y.(uint64), nil
>
> }
>
>
> To be more generic, this framework also support LuaJIT.
>
> There is a noticeable difference in terms of performance difference. LuaJIT
> is faster than pure Go. The profiling of pure Go showed the assertE2T and
> assertI2T cost a non-trivial amount of time.

Note that in the 1.8 release assertE2T and assertI2T no longer exist.
They were removed by https://golang.org/cl/32313.  That should speed
up these cases; assertE2T and assertI2T were trivial, but in some
cases they did call typedmemmove.  When your interface values store
non-pointers, and the code is inlined as it is in 1.8, the calls to
typedmemmove disappear.

You might want to retry your benchmarks with the 1.8 release candidate
to see if you can observe any real difference.

Ian

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: is it possible to speed up type assertion?

[Chris Lu]

Original poster here. Please do not call it micro benchmarking. My real
life use case is this.

I am trying to build a generic distributed map reduce system similar to
Spark. Without generics, the APIs pass data via interface{}. For example, a
reducer is written this way:

func sum(x, y interface{}) (interface{}, error) {

return x.(uint64) + y.(uint64), nil

}


To be more generic, this framework also support LuaJIT.

There is a noticeable difference in terms of performance difference. LuaJIT
is faster than pure Go. The profiling of pure Go showed the assertE2T
and assertI2T
cost a non-trivial amount of time.

In the original post, you can see pure Go with type casting took 8 seconds,
while LuaJIT only used 900 milliseconds to get the same amount of job done.

btw: Java took 30 ms to do the same. https://play.golang.org/p/FSnvLb2uxA
10% of time of pure go without any time casting.

Chris
See more about the framework on https://github.com/chrislusf/gleam


On Thu, Feb 2, 2017 at 10:53 AM, 'Axel Wagner' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> Making the gap smaller means making the compiler dumber. And I disagree
> with you about microbenchmarks. There is a difference between benchmarks
> and microbenchmarks and using the latter as the primary means of evaluating
> performance is plain wrong. Nothing wrong with artificial benchmarks in
> itself; if you benchmark how quickly a json-decoder decodes some artificial
> set of data is fine, it's reasonably close to real-world to give you some
> indication of performance. Benchmarking some code that will compile to only
> a handful of instructions will give you simply zero information.
>
> On Thu, Feb 2, 2017 at 7:46 PM, Jan Ziak <0xe2.0x9a.0...@gmail.com> wrote:
>
>> The compiler field hasn't so far reached a state of sophistication in
>> handling microbenchmarks like the human mind does handle them. Until that
>> state is reached in compiler technology, it is natural for people to keep
>> using microbenchmarks as one of the primary performance indicators.
>>
>> The observed difference is in [how a human mind would execute the
>> microbenchmark in order to execute it in the shortest amount of time
>> possible] compared to [how the microbenchmark is being executed on a real
>> CPU running instructions generated by a real compiler].
>>
>> Rational path for compiler technology is to make the observed gap
>> gradually smaller.
>>
>> On Thursday, February 2, 2017 at 6:56:09 PM UTC+1, Axel Wagner wrote:
>>>
>>> The point is, that (as repeatedly pointed out) microbenchmarks just, in
>>> general, don't tell you anything really useful, as any effects you measure
>>> could be due to anything ranging from random noise, over compiler
>>> optimizations to code-alignments. Avoiding type assertions based on
>>> anything contained in this thread is pretty unreasonable; I see zero
>>> evidence here, that they are, at all, a problem.
>>>
>>> Go gives you pretty amazing tools to find the actual bottlenecks in your
>>> code. Again: Write your code as it's most convenient, then run it with
>>> production data on production hardware and *if* it isn't fast enough,
>>> use pprof and similar tools to find the actual bottlenecks. They very
>>> likely won't be type-assertions.
>>>
>>> On Thu, Feb 2, 2017 at 5:16 PM, Jan Ziak <0xe2.0x...@gmail.com> wrote:
>>>
 A large difference between an implementable highly-optimized run-time
 performance of feature X and the physically implemented run-time
 performance of feature X causes programmers to avoid X.

 On Thursday, February 2, 2017 at 3:32:16 PM UTC+1, Marvin Renich wrote:
>
> * Marvin Renich  [170202 09:22]:
> >
> > BenchmarkIface is testing the wrong thing; the value is swamped by
> the
> > implicit conversion of d (type T) to the function argument of type
> I.
>
> Or, maybe it is testing the correct thing.  That is the problem with
> microbenchmarking.  Try benchmarking your actual code instead.  :-P
>
> ...Marvin
>
> --
 You received this message because you are subscribed to the Google
 Groups "golang-nuts" group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to golang-nuts...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

>>>
>>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-nuts+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/golang-nuts/Og8s9Y-Kif4/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> 

Re: [go-nuts] Re: is it possible to speed up type assertion?

['Axel Wagner' via golang-nuts]

Making the gap smaller means making the compiler dumber. And I disagree
with you about microbenchmarks. There is a difference between benchmarks
and microbenchmarks and using the latter as the primary means of evaluating
performance is plain wrong. Nothing wrong with artificial benchmarks in
itself; if you benchmark how quickly a json-decoder decodes some artificial
set of data is fine, it's reasonably close to real-world to give you some
indication of performance. Benchmarking some code that will compile to only
a handful of instructions will give you simply zero information.

On Thu, Feb 2, 2017 at 7:46 PM, Jan Ziak <0xe2.0x9a.0...@gmail.com> wrote:

> The compiler field hasn't so far reached a state of sophistication in
> handling microbenchmarks like the human mind does handle them. Until that
> state is reached in compiler technology, it is natural for people to keep
> using microbenchmarks as one of the primary performance indicators.
>
> The observed difference is in [how a human mind would execute the
> microbenchmark in order to execute it in the shortest amount of time
> possible] compared to [how the microbenchmark is being executed on a real
> CPU running instructions generated by a real compiler].
>
> Rational path for compiler technology is to make the observed gap
> gradually smaller.
>
> On Thursday, February 2, 2017 at 6:56:09 PM UTC+1, Axel Wagner wrote:
>>
>> The point is, that (as repeatedly pointed out) microbenchmarks just, in
>> general, don't tell you anything really useful, as any effects you measure
>> could be due to anything ranging from random noise, over compiler
>> optimizations to code-alignments. Avoiding type assertions based on
>> anything contained in this thread is pretty unreasonable; I see zero
>> evidence here, that they are, at all, a problem.
>>
>> Go gives you pretty amazing tools to find the actual bottlenecks in your
>> code. Again: Write your code as it's most convenient, then run it with
>> production data on production hardware and *if* it isn't fast enough,
>> use pprof and similar tools to find the actual bottlenecks. They very
>> likely won't be type-assertions.
>>
>> On Thu, Feb 2, 2017 at 5:16 PM, Jan Ziak <0xe2.0x...@gmail.com> wrote:
>>
>>> A large difference between an implementable highly-optimized run-time
>>> performance of feature X and the physically implemented run-time
>>> performance of feature X causes programmers to avoid X.
>>>
>>> On Thursday, February 2, 2017 at 3:32:16 PM UTC+1, Marvin Renich wrote:

 * Marvin Renich  [170202 09:22]:
 >
 > BenchmarkIface is testing the wrong thing; the value is swamped by
 the
 > implicit conversion of d (type T) to the function argument of type I.

 Or, maybe it is testing the correct thing.  That is the problem with
 microbenchmarking.  Try benchmarking your actual code instead.  :-P

 ...Marvin

 --
>>> You received this message because you are subscribed to the Google
>>> Groups "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to golang-nuts...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: is it possible to speed up type assertion?

[Jan Ziak]

The compiler field hasn't so far reached a state of sophistication in 
handling microbenchmarks like the human mind does handle them. Until that 
state is reached in compiler technology, it is natural for people to keep 
using microbenchmarks as one of the primary performance indicators.

The observed difference is in [how a human mind would execute the 
microbenchmark in order to execute it in the shortest amount of time 
possible] compared to [how the microbenchmark is being executed on a real 
CPU running instructions generated by a real compiler].

Rational path for compiler technology is to make the observed gap gradually 
smaller.

On Thursday, February 2, 2017 at 6:56:09 PM UTC+1, Axel Wagner wrote:
>
> The point is, that (as repeatedly pointed out) microbenchmarks just, in 
> general, don't tell you anything really useful, as any effects you measure 
> could be due to anything ranging from random noise, over compiler 
> optimizations to code-alignments. Avoiding type assertions based on 
> anything contained in this thread is pretty unreasonable; I see zero 
> evidence here, that they are, at all, a problem.
>
> Go gives you pretty amazing tools to find the actual bottlenecks in your 
> code. Again: Write your code as it's most convenient, then run it with 
> production data on production hardware and *if* it isn't fast enough, use 
> pprof and similar tools to find the actual bottlenecks. They very likely 
> won't be type-assertions.
>
> On Thu, Feb 2, 2017 at 5:16 PM, Jan Ziak <0xe2.0x...@gmail.com 
> > wrote:
>
>> A large difference between an implementable highly-optimized run-time 
>> performance of feature X and the physically implemented run-time 
>> performance of feature X causes programmers to avoid X.
>>
>> On Thursday, February 2, 2017 at 3:32:16 PM UTC+1, Marvin Renich wrote:
>>>
>>> * Marvin Renich  [170202 09:22]: 
>>> > 
>>> > BenchmarkIface is testing the wrong thing; the value is swamped by the 
>>> > implicit conversion of d (type T) to the function argument of type I. 
>>>
>>> Or, maybe it is testing the correct thing.  That is the problem with 
>>> microbenchmarking.  Try benchmarking your actual code instead.  :-P 
>>>
>>> ...Marvin 
>>>
>>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golang-nuts...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: is it possible to speed up type assertion?

['Axel Wagner' via golang-nuts]

The point is, that (as repeatedly pointed out) microbenchmarks just, in
general, don't tell you anything really useful, as any effects you measure
could be due to anything ranging from random noise, over compiler
optimizations to code-alignments. Avoiding type assertions based on
anything contained in this thread is pretty unreasonable; I see zero
evidence here, that they are, at all, a problem.

Go gives you pretty amazing tools to find the actual bottlenecks in your
code. Again: Write your code as it's most convenient, then run it with
production data on production hardware and *if* it isn't fast enough, use
pprof and similar tools to find the actual bottlenecks. They very likely
won't be type-assertions.

On Thu, Feb 2, 2017 at 5:16 PM, Jan Ziak <0xe2.0x9a.0...@gmail.com> wrote:

> A large difference between an implementable highly-optimized run-time
> performance of feature X and the physically implemented run-time
> performance of feature X causes programmers to avoid X.
>
> On Thursday, February 2, 2017 at 3:32:16 PM UTC+1, Marvin Renich wrote:
>>
>> * Marvin Renich  [170202 09:22]:
>> >
>> > BenchmarkIface is testing the wrong thing; the value is swamped by the
>> > implicit conversion of d (type T) to the function argument of type I.
>>
>> Or, maybe it is testing the correct thing.  That is the problem with
>> microbenchmarking.  Try benchmarking your actual code instead.  :-P
>>
>> ...Marvin
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: is it possible to speed up type assertion?

[Jan Ziak]

A large difference between an implementable highly-optimized run-time 
performance of feature X and the physically implemented run-time 
performance of feature X causes programmers to avoid X.

On Thursday, February 2, 2017 at 3:32:16 PM UTC+1, Marvin Renich wrote:
>
> * Marvin Renich  [170202 09:22]: 
> > 
> > BenchmarkIface is testing the wrong thing; the value is swamped by the 
> > implicit conversion of d (type T) to the function argument of type I. 
>
> Or, maybe it is testing the correct thing.  That is the problem with 
> microbenchmarking.  Try benchmarking your actual code instead.  :-P 
>
> ...Marvin 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: is it possible to speed up type assertion?

[Rene Kaufmann]

BenchmarkAssertion-4 3 4.08 ns/op
BenchmarkAssertionOK-4   5 3.03 ns/op
BenchmarkBare-4   5 3.01 ns/op
BenchmarkIface-4 300055.1 ns/op
BenchmarkReflect-4   112.8 ns/op

CPU: Intel(R) Core(TM) i5 CPU   M 540  @ 2.53GHz

On Thu, Feb 2, 2017 at 10:51 AM Dave Cheney  wrote:

> 0.44ns/op is about 2.2.ghz, the compiler has optimised away your
> microbenchmark.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: is it possible to speed up type assertion?

[Marvin Renich]

* Marvin Renich  [170202 09:22]:
> 
> BenchmarkIface is testing the wrong thing; the value is swamped by the
> implicit conversion of d (type T) to the function argument of type I.

Or, maybe it is testing the correct thing.  That is the problem with
microbenchmarking.  Try benchmarking your actual code instead.  :-P

...Marvin

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: is it possible to speed up type assertion?

[Marvin Renich]

* T L  [170202 04:20]:
> 
> 
> On Thursday, February 2, 2017 at 4:58:32 PM UTC+8, Axel Wagner wrote:
> >
> > Hi,
> >
> > I can not really reproduce your results. I rewrote your code to use the 
> > builtin benchmarking: http://sprunge.us/IfQc
> > Giving, on my laptop:
> >
> > BenchmarkAssertion-4 10 2.89 ns/op
> > BenchmarkAssertionOK-4   5 2.66 ns/op
> > BenchmarkBare-4   10 2.22 ns/op
> > BenchmarkIface-4 500030.0 ns/op
> > BenchmarkReflect-4   2 9.74 ns/op
> >
> > Note, that a) yes, there is an overhead of the type-assertion, but b) it's 
> > pretty small, especially compared to the other things you're trying and c) 
> > it can be further reduced by using the two-value form (so that there is 
> > never a need to consider stack-unwinding).
> >
> > Overall, this smells like a micro-benchmark. I wouldn't worry too much 
> > about it until you have specific evidence that it's slowing down a real 
> > program.
> >
> 
> The result on my machine for your test:
> BenchmarkAssertion-4 517.9 ns/op
> BenchmarkAssertionOK-4   517.9 ns/op
> BenchmarkBare-4  20 3.93 ns/op
> BenchmarkIface-4 186.7 ns/op
> BenchmarkReflect-4   515.6 ns/op

BenchmarkIface is testing the wrong thing; the value is swamped by the
implicit conversion of d (type T) to the function argument of type I.
Try:

func BenchmarkIface(b *testing.B) {
count := 0
var t T = 1
d := I(t)
for i := 0; i < b.N; i++ {
Iface(, d)
}
}

...Marvin

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: is it possible to speed up type assertion?

[mhhcbon]

is there a paper to read that introduces and explains benchmark pitfalls 
and BP for naive developers ?

there are papers out there which talks about go bench, it is sparse and 
often they pretext an obvious 
bad code to introduce the reader to the benchmarks go tooling .
Which is good, don't take me wrong, but that did not help me to avoid some 
pitfalls i faced IRL.

I suspect the topic is hairy to explain to beginners so they can be 
autonomous and confident,
in my experience and feeling, if you don t have a benchmarking background 
in other languages,
you are left to take the wrong decision because you can t produce the right 
understanding of the situation.

On Thursday, February 2, 2017 at 11:41:25 AM UTC+1, Axel Wagner wrote:
>
> I want to re-emphasize that all of these are micro-benchmarks. They say 
> nothing useful at all, as proven by this thread; in some circumstances, the 
> added cost may be significant, in others it isn't. The same rule that has 
> been repeated lots of times on this list still applies: Write your program 
> to be simple and readable, *if* it is too slow, benchmark and improve.​ 
> Basing your code on what any of these Benchmarks says is just ridiculous, 
> base it on the bottlenecks you measure in your actual, real-world program 
> running on the actual production hardware with actual production data.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: is it possible to speed up type assertion?

[T L]

On Thursday, February 2, 2017 at 6:01:19 PM UTC+8, T L wrote:
>
> I found that it is much faster if the dynamic values are pointers instead 
> of non-pointer.
>

By looking the code of function assertE2T in runtime/iface.go,
ot looks memmove(to, from unsafe.Pointer, n uintptr) is slow for values 
with size <= one word.
Currently, official gc doesn't make optimizations for types with size <= 
one word.
Pointers are treated as special value in interface.
 

>
> package main
>
> import (
> "testing"
> )
>
> func AssertInt(c *int, d interface{}) {
> *c += d.(int)
> }
>
> func BenchmarkAssertionInt(b *testing.B) {
> count := 0
> var t int = 1
> d := (interface{})(t)
> for i := 0; i < b.N; i++ {
> AssertInt(, d)
> }
> }
>
> func AssertPtr(c *int, d interface{}) {
> *c += *d.(*int)
> }
>
> func BenchmarkAssertionPtr(b *testing.B) {
> count := 0
> var t int = 1
> d := (interface{})()
> for i := 0; i < b.N; i++ {
> AssertPtr(, d)
> }
> }
>
> BenchmarkAssertionInt-4   515.3 ns/op
> BenchmarkAssertionPtr-4   20 3.09 ns/op
>
>
>
> On Thursday, February 2, 2017 at 2:04:23 PM UTC+8, ChrisLu wrote:
>>
>> Go's type assertion seems quite slow. The added cost is too much if it 
>> has to be in a tight loop. Here are the time taken on my laptop for the 
>> following code.
>>
>> https://play.golang.org/p/cA96miTkx_
>>
>>
>> chris$ time ./p
>> count=1073741824 time taken=7.899207181s
>> count=1073741824 time taken=300.601453ms
>>
>> real 0m8.205s
>> user 0m8.163s
>> sys 0m0.029s
>>
>> chris$ time luajit -e "count = 0
>> > for i=1, 1024*1024*1024, 1 do count = count + 1 end
>> > print(count)"
>> 1073741824
>>
>> real 0m0.900s
>> user 0m0.891s
>> sys 0m0.005s
>>
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: is it possible to speed up type assertion?

['Axel Wagner' via golang-nuts]

I want to re-emphasize that all of these are micro-benchmarks. They say
nothing useful at all, as proven by this thread; in some circumstances, the
added cost may be significant, in others it isn't. The same rule that has
been repeated lots of times on this list still applies: Write your program
to be simple and readable, *if* it is too slow, benchmark and improve.​
Basing your code on what any of these Benchmarks says is just ridiculous,
base it on the bottlenecks you measure in your actual, real-world program
running on the actual production hardware with actual production data.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: is it possible to speed up type assertion?

[T L]

I found that it is much faster if the dynamic values are pointers instead 
of non-pointer.

package main

import (
"testing"
)

func AssertInt(c *int, d interface{}) {
*c += d.(int)
}

func BenchmarkAssertionInt(b *testing.B) {
count := 0
var t int = 1
d := (interface{})(t)
for i := 0; i < b.N; i++ {
AssertInt(, d)
}
}

func AssertPtr(c *int, d interface{}) {
*c += *d.(*int)
}

func BenchmarkAssertionPtr(b *testing.B) {
count := 0
var t int = 1
d := (interface{})()
for i := 0; i < b.N; i++ {
AssertPtr(, d)
}
}

BenchmarkAssertionInt-4   515.3 ns/op
BenchmarkAssertionPtr-4   20 3.09 ns/op



On Thursday, February 2, 2017 at 2:04:23 PM UTC+8, ChrisLu wrote:
>
> Go's type assertion seems quite slow. The added cost is too much if it has 
> to be in a tight loop. Here are the time taken on my laptop for the 
> following code.
>
> https://play.golang.org/p/cA96miTkx_
>
>
> chris$ time ./p
> count=1073741824 time taken=7.899207181s
> count=1073741824 time taken=300.601453ms
>
> real 0m8.205s
> user 0m8.163s
> sys 0m0.029s
>
> chris$ time luajit -e "count = 0
> > for i=1, 1024*1024*1024, 1 do count = count + 1 end
> > print(count)"
> 1073741824
>
> real 0m0.900s
> user 0m0.891s
> sys 0m0.005s
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: is it possible to speed up type assertion?

[Dave Cheney]

0.44ns/op is about 2.2.ghz, the compiler has optimised away your 
microbenchmark. 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: is it possible to speed up type assertion?

[Steven Hartland]

On 02/02/2017 09:27, Ian Davis wrote:


On Thu, 2 Feb 2017, at 09:20 AM, T L wrote:



On Thursday, February 2, 2017 at 4:58:32 PM UTC+8, Axel Wagner wrote:

Hi,

I can not really reproduce your results. I rewrote your code to
use the builtin benchmarking: http://sprunge.us/IfQc
Giving, on my laptop:

BenchmarkAssertion-4 102.89 ns/op
BenchmarkAssertionOK-4 52.66 ns/op
BenchmarkBare-4 102.22 ns/op
BenchmarkIface-4 5000   30.0 ns/op
BenchmarkReflect-4 29.74 ns/op

Note, that a) yes, there is an overhead of the type-assertion,
but b) it's pretty small, especially compared to the other things
you're trying and c) it can be further reduced by using the
two-value form (so that there is never a need to consider
stack-unwinding).

Overall, this smells like a micro-benchmark. I wouldn't worry too
much about it until you have specific evidence that it's slowing
down a real program.


The result on my machine for your test:
BenchmarkAssertion-4 517.9 ns/op
BenchmarkAssertionOK-4 517.9 ns/op
BenchmarkBare-4 20 3.93 ns/op
BenchmarkIface-4 186.7 ns/op
BenchmarkReflect-4 515.6 ns/op


What version of Go and what OS/hardware?



Similar results here:
BenchmarkAssertion-24   1   14.4 ns/op
BenchmarkAssertionOK-24 1   14.0 ns/op
BenchmarkBare-2410   2.81 ns/op
BenchmarkIface-24   300040.2 ns/op
BenchmarkReflect-24 1   13.2 ns/op

go version go1.7.5 freebsd/amd64

CPU: Intel(R) Xeon(R) CPU E5-2640 0 @ 2.50GHz (2500.06-MHz K8-class CPU)

Regards
Steve

--
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: is it possible to speed up type assertion?

[T L]

On Thursday, February 2, 2017 at 5:28:26 PM UTC+8, Ian Davis wrote:
>
>
> On Thu, 2 Feb 2017, at 09:20 AM, T L wrote:
>
>
>
> On Thursday, February 2, 2017 at 4:58:32 PM UTC+8, Axel Wagner wrote:
>
> Hi,
>
> I can not really reproduce your results. I rewrote your code to use the 
> builtin benchmarking: http://sprunge.us/IfQc
> Giving, on my laptop:
>
> BenchmarkAssertion-4 10 2.89 ns/op
> BenchmarkAssertionOK-4   5 2.66 ns/op
> BenchmarkBare-4   10 2.22 ns/op
> BenchmarkIface-4 500030.0 ns/op
> BenchmarkReflect-4   2 9.74 ns/op
>
> Note, that a) yes, there is an overhead of the type-assertion, but b) it's 
> pretty small, especially compared to the other things you're trying and c) 
> it can be further reduced by using the two-value form (so that there is 
> never a need to consider stack-unwinding).
>
> Overall, this smells like a micro-benchmark. I wouldn't worry too much 
> about it until you have specific evidence that it's slowing down a real 
> program.
>
>
> The result on my machine for your test:
> BenchmarkAssertion-4 517.9 ns/op
> BenchmarkAssertionOK-4   517.9 ns/op
> BenchmarkBare-4  20 3.93 ns/op
> BenchmarkIface-4 186.7 ns/op
> BenchmarkReflect-4   515.6 ns/op
>
>
> What version of Go and what OS/hardware?
>
>
$ go version
go version go1.7.5 linux/amd64
$ cat /proc/cpuinfo | grep 'model name' | uniq
model name: Intel(R) Core(TM) i3-2350M CPU @ 2.30GHz
 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: is it possible to speed up type assertion?

[Ian Davis]

On Thu, 2 Feb 2017, at 09:20 AM, T L wrote:

> 

> 

> On Thursday, February 2, 2017 at 4:58:32 PM UTC+8, Axel Wagner wrote:
>> Hi,

>> 

>> I can not really reproduce your results. I rewrote your code to use
>> the builtin benchmarking: http://sprunge.us/IfQc
>> Giving, on my laptop:

>> 

>> BenchmarkAssertion-4  10  2.89 ns/op

>> BenchmarkAssertionOK-45  2.66 ns/op

>> BenchmarkBare-4   10  2.22 ns/op

>> BenchmarkIface-4  5000 30.0 ns/op

>> BenchmarkReflect-42  9.74 ns/op

>> 

>> Note, that a) yes, there is an overhead of the type-assertion, but b)
>> it's pretty small, especially compared to the other things you're
>> trying and c) it can be further reduced by using the two-value form
>> (so that there is never a need to consider stack-unwinding).
>> 

>> Overall, this smells like a micro-benchmark. I wouldn't worry too
>> much about it until you have specific evidence that it's slowing down
>> a real program.
> 

> The result on my machine for your test:

> BenchmarkAssertion-4 517.9 ns/op

> BenchmarkAssertionOK-4   517.9 ns/op

> BenchmarkBare-4  20 3.93 ns/op

> BenchmarkIface-4 186.7 ns/op

> BenchmarkReflect-4   515.6 ns/op



What version of Go and what OS/hardware?




-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: is it possible to speed up type assertion?

[T L]

On Thursday, February 2, 2017 at 5:20:01 PM UTC+8, T L wrote:
>
>
>
> On Thursday, February 2, 2017 at 4:58:32 PM UTC+8, Axel Wagner wrote:
>>
>> Hi,
>>
>> I can not really reproduce your results. I rewrote your code to use the 
>> builtin benchmarking: http://sprunge.us/IfQc
>> Giving, on my laptop:
>>
>> BenchmarkAssertion-4 10 2.89 ns/op
>> BenchmarkAssertionOK-4   5 2.66 ns/op
>> BenchmarkBare-4   10 2.22 ns/op
>> BenchmarkIface-4 500030.0 ns/op
>> BenchmarkReflect-4   2 9.74 ns/op
>>
>> Note, that a) yes, there is an overhead of the type-assertion, but b) 
>> it's pretty small, especially compared to the other things you're trying 
>> and c) it can be further reduced by using the two-value form (so that there 
>> is never a need to consider stack-unwinding).
>>
>> Overall, this smells like a micro-benchmark. I wouldn't worry too much 
>> about it until you have specific evidence that it's slowing down a real 
>> program.
>>
>
> The result on my machine for your test:
> BenchmarkAssertion-4 517.9 ns/op
> BenchmarkAssertionOK-4   517.9 ns/op
> BenchmarkBare-4  20 3.93 ns/op
> BenchmarkIface-4 186.7 ns/op
> BenchmarkReflect-4   515.6 ns/op
>
>
The difference after inclining the functions for iface is quite large:
https://play.golang.org/p/9PGknpwxPj

BenchmarkAssertion-4 514.8 ns/op
BenchmarkAssertionOK-4   514.9 ns/op
BenchmarkBare-4  20 0.44 ns/op
BenchmarkIface-4 20 0.44 ns/op
BenchmarkReflect-4   1010.6 ns/op

I guess CPU make some cache. 


 
>
>>
>> On Thu, Feb 2, 2017 at 9:40 AM, T L  wrote:
>>
>>> Type assertion is even slower than reflect: 
>>> https://play.golang.org/p/zvUTEKDfiL
>>>
>>> assert: count=33554432 time taken=499.061188ms
>>> direct: count=33554432 time taken=14.981847ms
>>> method: count=33554432 time taken=176.977503ms
>>> reflect: count=33554432 time taken=383.905004ms
>>>
>>> On Thursday, February 2, 2017 at 4:25:05 PM UTC+8, T L wrote:
>>>


 On Thursday, February 2, 2017 at 2:04:23 PM UTC+8, ChrisLu wrote:
>
> Go's type assertion seems quite slow. The added cost is too much if it 
> has to be in a tight loop. Here are the time taken on my laptop for the 
> following code.
>
> https://play.golang.org/p/cA96miTkx_
>
>
> chris$ time ./p
> count=1073741824 time taken=7.899207181s
> count=1073741824 time taken=300.601453ms
>
> real 0m8.205s
> user 0m8.163s
> sys 0m0.029s
>
> chris$ time luajit -e "count = 0
> > for i=1, 1024*1024*1024, 1 do count = count + 1 end
> > print(count)"
> 1073741824
>
> real 0m0.900s
> user 0m0.891s
> sys 0m0.005s
>
>
>
 Type assertion is even slower than call dynamic method: 
 https://play.golang.org/p/jUrazcbB9h
 Some surprised.
  

>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to golang-nuts...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: is it possible to speed up type assertion?

[T L]

On Thursday, February 2, 2017 at 4:58:32 PM UTC+8, Axel Wagner wrote:
>
> Hi,
>
> I can not really reproduce your results. I rewrote your code to use the 
> builtin benchmarking: http://sprunge.us/IfQc
> Giving, on my laptop:
>
> BenchmarkAssertion-4 10 2.89 ns/op
> BenchmarkAssertionOK-4   5 2.66 ns/op
> BenchmarkBare-4   10 2.22 ns/op
> BenchmarkIface-4 500030.0 ns/op
> BenchmarkReflect-4   2 9.74 ns/op
>
> Note, that a) yes, there is an overhead of the type-assertion, but b) it's 
> pretty small, especially compared to the other things you're trying and c) 
> it can be further reduced by using the two-value form (so that there is 
> never a need to consider stack-unwinding).
>
> Overall, this smells like a micro-benchmark. I wouldn't worry too much 
> about it until you have specific evidence that it's slowing down a real 
> program.
>

The result on my machine for your test:
BenchmarkAssertion-4 517.9 ns/op
BenchmarkAssertionOK-4   517.9 ns/op
BenchmarkBare-4  20 3.93 ns/op
BenchmarkIface-4 186.7 ns/op
BenchmarkReflect-4   515.6 ns/op

 

>
> On Thu, Feb 2, 2017 at 9:40 AM, T L  
> wrote:
>
>> Type assertion is even slower than reflect: 
>> https://play.golang.org/p/zvUTEKDfiL
>>
>> assert: count=33554432 time taken=499.061188ms
>> direct: count=33554432 time taken=14.981847ms
>> method: count=33554432 time taken=176.977503ms
>> reflect: count=33554432 time taken=383.905004ms
>>
>> On Thursday, February 2, 2017 at 4:25:05 PM UTC+8, T L wrote:
>>
>>>
>>>
>>> On Thursday, February 2, 2017 at 2:04:23 PM UTC+8, ChrisLu wrote:

 Go's type assertion seems quite slow. The added cost is too much if it 
 has to be in a tight loop. Here are the time taken on my laptop for the 
 following code.

 https://play.golang.org/p/cA96miTkx_


 chris$ time ./p
 count=1073741824 time taken=7.899207181s
 count=1073741824 time taken=300.601453ms

 real 0m8.205s
 user 0m8.163s
 sys 0m0.029s

 chris$ time luajit -e "count = 0
 > for i=1, 1024*1024*1024, 1 do count = count + 1 end
 > print(count)"
 1073741824

 real 0m0.900s
 user 0m0.891s
 sys 0m0.005s



>>> Type assertion is even slower than call dynamic method: 
>>> https://play.golang.org/p/jUrazcbB9h
>>> Some surprised.
>>>  
>>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golang-nuts...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: is it possible to speed up type assertion?

['Axel Wagner' via golang-nuts]

Hi,

I can not really reproduce your results. I rewrote your code to use the
builtin benchmarking: http://sprunge.us/IfQc
Giving, on my laptop:

BenchmarkAssertion-4 10 2.89 ns/op
BenchmarkAssertionOK-4   5 2.66 ns/op
BenchmarkBare-4   10 2.22 ns/op
BenchmarkIface-4 500030.0 ns/op
BenchmarkReflect-4   2 9.74 ns/op

Note, that a) yes, there is an overhead of the type-assertion, but b) it's
pretty small, especially compared to the other things you're trying and c)
it can be further reduced by using the two-value form (so that there is
never a need to consider stack-unwinding).

Overall, this smells like a micro-benchmark. I wouldn't worry too much
about it until you have specific evidence that it's slowing down a real
program.

On Thu, Feb 2, 2017 at 9:40 AM, T L  wrote:

> Type assertion is even slower than reflect: https://play.golang.org/p/
> zvUTEKDfiL
>
> assert: count=33554432 time taken=499.061188ms
> direct: count=33554432 time taken=14.981847ms
> method: count=33554432 time taken=176.977503ms
> reflect: count=33554432 time taken=383.905004ms
>
> On Thursday, February 2, 2017 at 4:25:05 PM UTC+8, T L wrote:
>
>>
>>
>> On Thursday, February 2, 2017 at 2:04:23 PM UTC+8, ChrisLu wrote:
>>>
>>> Go's type assertion seems quite slow. The added cost is too much if it
>>> has to be in a tight loop. Here are the time taken on my laptop for the
>>> following code.
>>>
>>> https://play.golang.org/p/cA96miTkx_
>>>
>>>
>>> chris$ time ./p
>>> count=1073741824 time taken=7.899207181s
>>> count=1073741824 time taken=300.601453ms
>>>
>>> real 0m8.205s
>>> user 0m8.163s
>>> sys 0m0.029s
>>>
>>> chris$ time luajit -e "count = 0
>>> > for i=1, 1024*1024*1024, 1 do count = count + 1 end
>>> > print(count)"
>>> 1073741824
>>>
>>> real 0m0.900s
>>> user 0m0.891s
>>> sys 0m0.005s
>>>
>>>
>>>
>> Type assertion is even slower than call dynamic method:
>> https://play.golang.org/p/jUrazcbB9h
>> Some surprised.
>>
>>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: is it possible to speed up type assertion?

[T L]

Type assertion is even slower than reflect: 
https://play.golang.org/p/zvUTEKDfiL

assert: count=33554432 time taken=499.061188ms
direct: count=33554432 time taken=14.981847ms
method: count=33554432 time taken=176.977503ms
reflect: count=33554432 time taken=383.905004ms

On Thursday, February 2, 2017 at 4:25:05 PM UTC+8, T L wrote:
>
>
>
> On Thursday, February 2, 2017 at 2:04:23 PM UTC+8, ChrisLu wrote:
>>
>> Go's type assertion seems quite slow. The added cost is too much if it 
>> has to be in a tight loop. Here are the time taken on my laptop for the 
>> following code.
>>
>> https://play.golang.org/p/cA96miTkx_
>>
>>
>> chris$ time ./p
>> count=1073741824 time taken=7.899207181s
>> count=1073741824 time taken=300.601453ms
>>
>> real 0m8.205s
>> user 0m8.163s
>> sys 0m0.029s
>>
>> chris$ time luajit -e "count = 0
>> > for i=1, 1024*1024*1024, 1 do count = count + 1 end
>> > print(count)"
>> 1073741824
>>
>> real 0m0.900s
>> user 0m0.891s
>> sys 0m0.005s
>>
>>
>>
> Type assertion is even slower than call dynamic method: 
> https://play.golang.org/p/jUrazcbB9h
> Some surprised.
>  
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: is it possible to speed up type assertion?

[T L]

On Thursday, February 2, 2017 at 4:25:05 PM UTC+8, T L wrote:
>
>
>
> On Thursday, February 2, 2017 at 2:04:23 PM UTC+8, ChrisLu wrote:
>>
>> Go's type assertion seems quite slow. The added cost is too much if it 
>> has to be in a tight loop. Here are the time taken on my laptop for the 
>> following code.
>>
>> https://play.golang.org/p/cA96miTkx_
>>
>>
>> chris$ time ./p
>> count=1073741824 time taken=7.899207181s
>> count=1073741824 time taken=300.601453ms
>>
>> real 0m8.205s
>> user 0m8.163s
>> sys 0m0.029s
>>
>> chris$ time luajit -e "count = 0
>> > for i=1, 1024*1024*1024, 1 do count = count + 1 end
>> > print(count)"
>> 1073741824
>>
>> real 0m0.900s
>> user 0m0.891s
>> sys 0m0.005s
>>
>>
>>
> Type assertion is even slower than call dynamic method: 
> https://play.golang.org/p/jUrazcbB9h
> Some surprised.
>

The result:
assert: count=5242880 time taken=79.262474ms
direct: count=5242880 time taken=2.291717ms
method: count=5242880 time taken=27.456853ms
 

>  
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: is it possible to speed up type assertion?

[T L]

On Thursday, February 2, 2017 at 2:04:23 PM UTC+8, ChrisLu wrote:
>
> Go's type assertion seems quite slow. The added cost is too much if it has 
> to be in a tight loop. Here are the time taken on my laptop for the 
> following code.
>
> https://play.golang.org/p/cA96miTkx_
>
>
> chris$ time ./p
> count=1073741824 time taken=7.899207181s
> count=1073741824 time taken=300.601453ms
>
> real 0m8.205s
> user 0m8.163s
> sys 0m0.029s
>
> chris$ time luajit -e "count = 0
> > for i=1, 1024*1024*1024, 1 do count = count + 1 end
> > print(count)"
> 1073741824
>
> real 0m0.900s
> user 0m0.891s
> sys 0m0.005s
>
>
>
Type assertion is even slower than call dynamic method: 
https://play.golang.org/p/jUrazcbB9h
Some surprised.
 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: is it possible to speed up type assertion?

[T L]

On Thursday, February 2, 2017 at 2:04:23 PM UTC+8, ChrisLu wrote:
>
> Go's type assertion seems quite slow. The added cost is too much if it has 
> to be in a tight loop. Here are the time taken on my laptop for the 
> following code.
>
> https://play.golang.org/p/cA96miTkx_
>
>
> chris$ time ./p
> count=1073741824 time taken=7.899207181s
> count=1073741824 time taken=300.601453ms
>
> real 0m8.205s
> user 0m8.163s
> sys 0m0.029s
>
> chris$ time luajit -e "count = 0
> > for i=1, 1024*1024*1024, 1 do count = count + 1 end
> > print(count)"
> 1073741824
>
> real 0m0.900s
> user 0m0.891s
> sys 0m0.005s
>
>
Can't believe it, type assertion is even slow than call interface method: 
https://play.golang.org/p/3if6xECkVk

count=5242880 time taken=76.27149ms
count=5242880 time taken=2.289666ms
count=5242880 time taken=27.244965ms

 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.