Howdy,
On Sun, Dec 6, 2009 at 5:17 AM, James E Keenan wrote:
> For those of us who are unfamiliar with Euler Project Problems (as I was):
>
> http://projecteuler.net/index.php?section=problems
>
> http://en.wikipedia.org/wiki/Project_Euler
>
> Jonathan: Are these often used as benchmarks?
>
> k
Howdy,
Looking at our benchmarks, I didn't see anything that looked like it
benchmarked string operations very much, so I whipped up a small PIR
script to calculate the Hamming distance between two strings. It is
mostly good for looking at the performance of String PMC -> string
conversion, substr
Howdy,
This file is a GC stress test and it tells a story. Parrot's GC got
seriously slow in 1.5.0 and 1.6.0, but we have really made great
strides since 1.7.0 to make it faster. Given all this, older Parrot's
were still faster than trunk by about 10%.
http://gist.github.com/250669
Duke
--
J
Howdy,
Sadly, the results look the same with --count=100:
http://gist.github.com/250648
Duke
On Sun, Dec 6, 2009 at 9:02 PM, Jonathan Leto wrote:
> Howdy,
>
> I just realized that I gist'ed the output for a run with a --count of
> 1 (which I do to see if stuff segaults/parses), instead of th
Howdy,
I just realized that I gist'ed the output for a run with a --count of
1 (which I do to see if stuff segaults/parses), instead of the normal
100. I am running the benchmark again and will post updated results
soon.
Duke
PS: Thanks to pmichaud++ for noticing
On Sun, Dec 6, 2009 at 7:59 PM,
Howdy,
Looks like our array access is twice as slow in trunk then in 1.8.0.
This is probably seriously hurting us due to the amount of arrays PCC
creates during parsing.
http://gist.github.com/250599
PS: Most benchmarks from now on will only go back to 0.5.0, since
testing Parrot's before that o
From: "Patrick R. Michaud"
Date: Sun, 6 Dec 2009 00:01:24 -0600
TT #1091 and DEPRECATED.pod claim that label-based exception
handlers are eligible to be removed in 2.1. I think label-based
exception handlers are necessary; but I'm willing to be proven wrong.
If a handler "should
On 12/06/2009 06:22 PM, chromatic wrote:
On Sunday 06 December 2009 at 08:06, Geoffrey Broadwell wrote:
While I would love for HEAD to be always the fastest, if you mentally
graph this you can see that trunk is in the main grouping of total times
in the 32 to 40 second range. It's the outl
On Sun, 2009-12-06 at 16:22 -0800, chromatic wrote:
> I don't trust time-related benchmarkings for this reason. Yes, stochastic
> analysis can give you some degree of probability that comparisons are all
> like-to-like, but the output of a single Callgrind run is much easier to
> compare (and g
On Sunday 06 December 2009 at 08:06, Geoffrey Broadwell wrote:
> While I would love for HEAD to be always the fastest, if you mentally
> graph this you can see that trunk is in the main grouping of total times
> in the 32 to 40 second range. It's the outliers in the 55 to 74 second
> range that r
On Sun, 2009-12-06 at 13:58 -0800, chromatic wrote:
> On Sunday 06 December 2009 at 11:18, Patrick R wrote:
>
> > Beyond that, I do not agree with any premise that HLLs will benefit
> > from the optimizations this sort of analysis can achieve.
Ah, I fear I was dreadfully unclear with what I was
On Sunday 06 December 2009 at 11:18, Patrick R wrote:
> Beyond that, I do not agree with any premise that HLLs will benefit
> from the optimizations this sort of analysis can achieve.
Benchmarks which point out bottlenecks in:
* intrinsic PMC performance (Hash, NameSpace, Sub)
*
On Sun, Dec 06, 2009 at 08:06:50AM -0800, Geoffrey Broadwell wrote:
> On Sun, 2009-12-06 at 01:33 -0800, Jonathan Leto wrote:
> > This one is all over the place and trunk is not looking very pretty.
> > http://gist.github.com/250139
>
> 1. Make sure HEAD is in the same grouping as the fastest time
On Sun, 2009-12-06 at 01:33 -0800, Jonathan Leto wrote:
> This one is all over the place and trunk is not looking very pretty.
>
> http://gist.github.com/250139
While I would love for HEAD to be always the fastest, if you mentally
graph this you can see that trunk is in the main grouping of total
Jonathan Leto wrote:
Howdy,
For those of us who are unfamiliar with Euler Project Problems (as I was):
http://projecteuler.net/index.php?section=problems
http://en.wikipedia.org/wiki/Project_Euler
Jonathan: Are these often used as benchmarks?
kid51
Howdy,
This one is all over the place and trunk is not looking very pretty.
Duke
http://gist.github.com/250139
--
Jonathan "Duke" Leto
jonat...@leto.net
http://leto.net
___
http://lists.parrot.org/mailman/listinfo/parrot-dev
Howdy again,
Correction, both of these are EP #001 not #002.
Duke
On Sun, Dec 6, 2009 at 12:43 AM, Jonathan Leto wrote:
> Howdy,
>
> I just ran another slight variant of this algorithm, which eschews
> Integer PMCs and just uses named integer registers via .local .
> Surprisingly. Parrot 1.3.
Howdy,
I just ran another slight variant of this algorithm, which eschews
Integer PMCs and just uses named integer registers via .local .
Surprisingly. Parrot 1.3.0 sneaks just ahead of trunk (r42903) in this
case.
http://gist.github.com/250132
Duke
On Sun, Dec 6, 2009 at 12:25 AM, Jonathan Le
Howdy,
Summary: EP #2 is to find the sum of the integers less than 1000 which
are divisible by 3 or 5.
This benchmark is simple, with no function calls and only simple
Integer PMCs being created, with a few mod, inc and add ops going on.
Trunk (r42903) is the fastest ever. Great job, people!
htt
19 matches
Mail list logo
