[Bug 588941] Review Request: pypy - Implementation of the Python language, using Python itself

[bugzilla at redhat.com]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=588941

--- Comment #32 from Dave Malcolm <dmalcolm at redhat.com> 2010-12-16 20:45:39 EST ---
(In reply to comment #11)
...
> 1) License tag is better.  dmalcolm:  I found the list of licenses that had
> been included in the spec file present in the LICENSE file.  If that's where
> you got the original list from then the license tag should now be correct.  I
> was able to remove LGPL and Distributable because those were coming from
> bundled jar files.  I removed the bundled jars (see below) so that should now
> be fine.
The LICENSE file is indeed where I got that list from.  I haven't yet gone
through the full tarball payload.


> 4) The build isn't make driven but I didn't look at parallelizing it.
The compilation phase invokes a Makefile; on my machine it used "-j 4", and in
one of the Koji scratch builds it used "-j 10"
It appears to come from this code in
pypy-1.4/pypy/translator/c/genc.py:compile:
>            if self.config.translation.make_jobs != 1:
>                 extra_opts += ['-j', str(self.config.translation.make_jobs)]
which in turn is intialized in this code in
pypy-1.4/pypy/config/translationoption.py:
              cmdline="--make-jobs", default=detect_number_of_processors()),

Hopefully that's good enough for our build system.

It's actually visible in the built binary, FWIW:
>  $ ./pypy --info|grep make_jobs
>  translation.make_jobs: 4

Unfortunately that parallelizable phase is only a small fraction of the build
time (see "compile_c" below); from the x86_64 scratch build's log:
[Timer] Timings:
[Timer] annotate                       ---  780.8 s
[Timer] rtype_lltype                   ---  491.7 s
[Timer] pyjitpl_lltype                 ---  712.2 s
[Timer] backendopt_lltype              ---  202.3 s
[Timer] stackcheckinsertion_lltype     ---   21.6 s
[Timer] database_c                     ---  243.8 s
[Timer] source_c                       ---  477.3 s
[Timer] compile_c                      ---  148.4 s
[Timer] ===========================================
[Timer] Total:                         --- 3078.2 s
real 52m21.339s
user 49m43.905s
sys 0m3.552s

so roughly 15% of that build time benefited from the 10 cores on that machine
(presumably, would have been ~1480 seconds otherwise, so that at least is a
significant saving).

As I understand it, parallelizing the rest of the build would involve major
rewrites (it's all in one big cpython process)



> 5) rpmlint c): Yeah, it's because it's named -libs.  Another possible name is
> -stdlib since it is the python stdlib(for pypy).
Did moving to versioned requirements fix this?


> 5e) I was waiting for the koji build to complete to see if this is still an
> issue with 1.4.
Seems to have been fixed, either in 1.4, or in Toshio's work on the specfile.


> 5f) dmalcolm, what did we decide to do with this on the python and python3
> packages?
I've copied a fixer-upper from the python3 specfile in my 1.4-4 pypy.spec

> Other:
> * Removed bundled jar files.  Pre-built files are not allowed.  It looks like
> these were present in case we were building a pypy that targets the jvm (rather
> than POSIX-C).  Simple removal should be fine until/unless we want to enable
> that backend.  If we do enable that, one of the jar files is packaged for
BTW, I considered building that one.  The impression I get is that the JVM
backend isn't as mature as the .c backend, so it seems simplest to omit it for
now.  (fijal: do you have any advice/guidance on this?)

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.