Best news (new to me anyway!) I've read all day. :) Thanks!
On Wed, Oct 30, 2013 at 4:20 PM, Amaury Forgeot d'Arc
wrote:
> 2013/10/30 Taavi Burns
>>
>> Unless I missed something (possible!) the JIT and STM are mutually
>> exclusive (until implemented).
>
>
> In the last post about STM:
> http://
Davide,
Thanks for posting your numbers. I think they are interesting and the 11x
speedup for 16 threads is not bad, however the overhead of STM is still too
high compared to PyPy.
well, yes and no: richards.py runs 30x faster on PyPy than on CPython. The
more typical speedup of PyPy is 5x,
Amaury,
On Wed, 30 Oct 2013, Amaury Forgeot d'Arc wrote:
Also, the process should perform 1000 iterations before you start the
timings.
The JIT needs a lot of iterations to be warm-up correctly.
so, each 'iteration' that I had in the table contains an inner loop that
is itself JIT-ed (not veri
2013/10/30 Taavi Burns
> Unless I missed something (possible!) the JIT and STM are mutually
> exclusive (until implemented).
>
In the last post about STM:
http://morepypy.blogspot.ch/2013/10/update-on-stm.html
"For comparison, disabling the JIT gives 492ms on PyPy-2.1 and 538ms on
PyPy-STM."
JI
Unless I missed something (possible!) the JIT and STM are mutually exclusive
(until implemented).
--
taa
/*eof*/
> On Oct 30, 2013, at 14:45, "Amaury Forgeot d'Arc" wrote:
>
> 2013/10/30 Davide Del Vento
>> Hi Wim,
>>
>> Thanks for posting your numbers. I think they are interesting and the
2013/10/30 Davide Del Vento
> Hi Wim,
>
> Thanks for posting your numbers. I think they are interesting and the 11x
> speedup for 16 threads is not bad, however the overhead of STM is still too
> high compared to PyPy. Maybe you need also a larger dataset, besides a
> longer time?
>
>
> > I shoul
Hi Wim,
Thanks for posting your numbers. I think they are interesting and the
11x speedup for 16 threads is not bad, however the overhead of STM is
still too high compared to PyPy. Maybe you need also a larger dataset,
besides a longer time?
> I should run this multiple
> times and average,
Hi Armin,
On 10/29/2013 03:54 PM, Armin Rigo wrote:
On Tue, Oct 29, 2013 at 6:21 PM, Davide Del Vento wrote:
I don't know. But I do know that processor/thread binding (if that is what
you mean by "pin") is *extremely* important in Sandy Bridge, even more than
on previous archs. And, oddly enou
Davide,
I don't know. But I do know that processor/thread binding (if that is what
you mean by "pin")
is what I meant. :) But a q&d implementation does not seem to make much
difference other than for 8 and 16 threads, where it helps a bit.
Running some more, I noticed that there are plenty of
Hi Davide,
On Tue, Oct 29, 2013 at 6:21 PM, Davide Del Vento wrote:
> I don't know. But I do know that processor/thread binding (if that is what
> you mean by "pin") is *extremely* important in Sandy Bridge, even more than
> on previous archs. And, oddly enough, in my experience is more difficult
On 10/28/2013 05:58 PM, wlavrij...@lbl.gov wrote:
Has any attempt
been made to pin threads?
I don't know. But I do know that processor/thread binding (if that is
what you mean by "pin") is *extremely* important in Sandy Bridge, even
more than on previous archs. And, oddly enough, in my experi
11 matches
Mail list logo
