Commits

Anonymous committed aeba33f

Better line wrapping.

  • Participants
  • Parent commits 3b49627

Comments (0)

Files changed (1)

blog/challenges.rst

   This is less of a concern for users, but more of a concern for developers
   and potential developers.
 
-* **Memory impact**. We never scientifically measured
-  memory impact of PyPy on examples. There are reports of outrageous pypy
-  memory usage, but they're usually very cryptic "my app uses 300M" and not
-  really reported in a way that's reproducible for us. We simply have to start
-  measuring memory impact on benchmarks. You can definitely help by providing
-  us with reproducible examples (they don't have to be small, but they have
+* **Memory impact**. We never scientifically measured memory impact of PyPy
+  on examples. There are reports of outrageous pypy memory usage, but
+  they're usually very cryptic "my app uses 300M" and not really reported
+  in a way that's reproducible for us. We simply have to start measuring
+  memory impact on benchmarks. You can definitely help by providing us
+  with reproducible examples (they don't have to be small, but they have
   to be open source).
 
 The next group all are connected. The fundamental question is: What to do
 be addressed by one or more of the following:
 
 * **Slow runtime**. Our runtime is slow. This is caused by a combination
-  of using a higher
-  level language than C and a relative immaturity compared to CPython. The
-  former is at least partly a GCC problem. We emit code that does not look
-  like hand-written C and GCC is doing worse job at optimizing it. A good
-  example is operations on longs, which are about 2x slower than CPython's,
-  partly because GCC is unable to effectively optimize code generated
-  by PyPy's translator.
+  of using a higher level language than C and a relative immaturity
+  compared to CPython. The former is at least partly a GCC problem. We
+  emit code that does not look like hand-written C and GCC is doing worse
+  job at optimizing it. A good example is operations on longs, which are
+  about 2x slower than CPython's, partly because GCC is unable to
+  effectively optimize code generated by PyPy's translator.
 
 * **Too large JIT warmup time**. This is again a combination of issues.
   Partly this is one of the design decisions of tracing on the metalevel,
   manpower to proceed as rapidly as we would like.
 
 Thanks for bearing with me this far. This blog post was partly influenced
-by accusations that we're doing dishonest PR that PyPy is always fast. I don't
-think this is the case and I hope I clarified some of the weak spots, both here
-and on the `performance page`_.
+by accusations that we're doing dishonest PR that PyPy is always fast. I
+don't think this is the case and I hope I clarified some of the weak spots,
+both here and on the `performance page`_.
 
 Cheers,
 fijal