On Mon, Jan 11, 2010 at 03:42:27PM -0600, Mike Gerdts wrote:
> On Fri, Jan 8, 2010 at 5:19 PM, Danek Duvall <[email protected]> wrote:
> > [email protected] wrote:
> >
> >> > Are there other components you think might benefit from optimization?
> >>
> >> We're delivering the other two that seemed interesting to me: pycurl and
> >> SAT solver.
> >
> > Does pycurl have any real code in it? ?I thought it was just a shim on top
> > of libcurl. ?If so, then I doubt it'll get any speedup from optimization;
> > we just need to make sure that libcurl itself is properly optimized.
> >
> > And the SAT solver gets taken care of by my patch.
>
> Are there timings out there for areas of C code that are still slow
> and CPU bound? Has anyone considered OpenMP for these?
In general, Python calls out to C routines when it needs optimized code,
or it needs to interface with a libarary that's only written in C. I
got involved in investigating the SPARC performance after writing a
protoype using Python's Multiprocessing library. It has a bunch of
different primitives for parallel programming.
http://docs.python.org/library/multiprocessing.html
However, I didn't see any performance gains by performing the zlib
decompression in parallel. I'm in the process of wrapping up a
preliminary investigation into architectural / OS issues that are
affecting SPARC performance. Once I have that under control, I'll be
taking another look at the algorithimic issues. I did some profiling
right before Christmas, but I haven't had a chance to drill down into
the trouble spots yet.
-j
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
