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 <
[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> [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 [email protected].
>>>> 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 [email protected].
>> 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
> [email protected].
> 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 [email protected].
For more options, visit https://groups.google.com/d/optout.
