From @zoffixznet

While playing around, I noticed the of .hyper produces very strange results. First, a control, without .hyper that consistently clocks in at around 2.3 seconds on my 2-core machine​:

$ perl6 -e '.base​: 16 for ^100000; say now - INIT now'
2.33417984

If we include the .hyper method, however, about 50% of the time, we get ridiculously faster results​: 58 times faster; or ridiculously slower results​: 19 times slower​:

$ perl6 -e '.base​: 16 for ^100000 .hyper; say now - INIT now'
0.0470114
$ perl6 -e '.base​: 16 for ^100000 .hyper; say now - INIT now'
34.64521881

My expected result is the use of .hyper would produce a marginal speed increase, utilizing my second core, and performing the computation between 0%–100% faster.

See also RT#​127364 for .race, which also produces results much slower than normal version, although I did not observe the inconsistency with speeds​: https://rt-archive.perl.org/perl6/Ticket/Display.html?id=127364

From @zoffixznet

On Mon, 25 Jan 2016 09​:11​:13 -0800, cpan@​zoffix.com wrote​:

While playing around, I noticed the of .hyper produces very strange
results. First, a control, without .hyper that consistently clocks in
at around 2.3 seconds on my 2-core machine​:

$ perl6 -e '.base​: 16 for ^100000; say now - INIT now'
2.33417984

If we include the .hyper method, however, about 50% of the time, we
get ridiculously faster results​: 58 times faster; or ridiculously
slower results​: 19 times slower​:

$ perl6 -e '.base​: 16 for ^100000 .hyper; say now - INIT now'
0.0470114
$ perl6 -e '.base​: 16 for ^100000 .hyper; say now - INIT now'
34.64521881

My expected result is the use of .hyper would produce a marginal speed
increase, utilizing my second core, and performing the computation
between 0%–100% faster.

See also RT#​127364 for .race, which also produces results much slower
than normal version, although I did not observe the inconsistency with
speeds​: https://rt-archive.perl.org/perl6/Ticket/Display.html?id=127364

This was filed before .hyper was properly made and I don't see any perf anomalies in current implementation.

@zoffixznet - Status changed from 'new' to 'resolved'