Just Launched: You can now import projects and releases from Google Code onto SourceForge
We are excited to release new functionality to enable a 1-click import from Google Code onto the Allura platform on SourceForge. You can import tickets, wikis, source, releases, and more with a few simple steps. Read More
From: Kevin Jacobs <jacobs@pe...> - 2002-01-13 22:33:56
On Fri, 11 Jan 2002, Tim Hochberg wrote:
> Welcome! I just showed up here myseld, but of my eventual goals is to see if
> either NumPy or NumPy2 (or whatever the supposed successor to NumPy is
> called these days) arrays can be virtualized. I assume you're talking about
> Python's builtin array type, but I'd love to see you get that working so
> that I could steal, er I mean model my code off of yours.
Hopefully we can work together to find an efficient method to virtualize
many types of Python objects. I'm in the process of digesting how much
data-flow information is available in the current Psyco implementation.
Then we can start discussing how to generate very general code for
boxing/unboxing data types, and detecting places where it will be a clear
gain to do so. Right now, it seems that most Psyco code involving
non-integer data is geared around low-overhead manipulation of boxed types.
This strategy by itself will result in only fairly modest performance gains
for dynamically typed collections. However much larger gains are feasible
for a clever implementation that does just the right amount of work to
box/unbox types and inline specialized functions. As a first step toward
this, I'll be working mainly on statically typed and homogenious containers
like Python array and string objects. Of course, this should naturally
extend to cover NumPy containers.
 I'm specifically looking for data-flow information regarding variable
"liveness", side-effect detection, and aliasing. This type of
information is not hard to generate, especially when generated
incrementally as variables and types are promoted from "compiler time"
to "runtime" or "virtual time".
 Boxed type instances are typically heap allocated objects that represent
a collection of primitive and boxed type instances (e.g. Python
objects). Unboxed instances are an internal 'flattened' representation
of the boxed objects into its constituent components. For example, say
we have the tuple (1,2,3). It can be unboxed by assigning registers
AX=1, BX=2, CX=3. Since tuples are immutable, we generally don't have
to (re)box them unless a reference to that tuple escapes the current code
block. Lists and array objects work very similarly. From past
experience, I've found it much easier to deal with boxing/unboxing
strongly typed containers (like array module objects, Numeric Python
vectors) than with heterogeneous typed containers (like Python lists,
tuples, dictionaries, etc.).
The OPAL Group - Enterprise Systems Architect
Voice: (216) 986-0710 x 19 E-mail: jacobs@...
Fax: (216) 986-0714 WWW: http://www.theopalgroup.com