Amaury wrote:
>Surely we could have another copy with the largeadressaware flag?
I agree. That's a smart way to proceed for now.
I'm still wondering if there is any technical reason against the flag?
Particularly the "CFFI extensions want the high bit reserved or not" issue.
Matt wrote:
I think we score pretty good on this benchmark. Definitely the
competition there is tough (v8, luajit are the only other dynamic lang
implementations considered).
There is a plan to improve on *such* code, but definitely our
immediate plans are for more python-like workloads than number
crunching.
The biggest problem with this benchmark is that it uses nested lists (read:
memory indirections), whereas the other implementations (or at least the C
one) uses flat storage.
Alex
On Sun, Apr 7, 2013 at 4:30 AM, Dimitri Vorona wrote:
> Hi everyone,
>
> just wanted to bring to your attention thi
Hi:
About PyPy's sandbox,I want to ask you a question:
In PyPy's sandbox ,a lot of standard libraries can not be used.If I want
use it,how could I add it in PyPy's sandbox?
(you can assume I have verify the module's safety)
___
pypy-dev mailing list
pypy-
Hi everyone,
just wanted to bring to your attention this blog post:
http://attractivechaos.wordpress.com/2013/04/06/performance-of-rust-and-dart-in-sudoku-solving/
.
PyPy ist compared with various dynamic and static languages.
While the perfomance is still OK (within an order of magnitude of C),
Hi Amaury,
On Sun, Apr 7, 2013 at 10:57 AM, Amaury Forgeot d'Arc
wrote:
> In the nightly distribution, pypy.exe is only 7kb.
> Surely we could have another copy with the largeadressaware flag?
+1 Great idea.
Armin
___
pypy-dev mailing list
pypy-dev@py
2013/4/6 matti picus
> I would vote -1 for adding the largeaddressaware
> flag to our translation proccess for nightlies. Better to run out of
> memory than to use cffi to call some random dll andhave it explode. Those
> who are in the know will have a compiler or can down load a free version
> a
