Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #2366 > unrolled thread

Python CPU

Back to article view | Back to comp.lang.python

Contents

  Python CPU Brad <hwfwguy@gmail.com> - 2011-04-01 08:38 -0700
    Re: Python CPU jkn <jkn_gg@nicorp.f9.co.uk> - 2011-04-01 08:59 -0700
    Re: Python CPU Nobody <nobody@nowhere.com> - 2011-04-01 17:52 +0100
      Re: Python CPU Stefan Behnel <stefan_ml@behnel.de> - 2011-04-01 19:00 +0200
      Re: Python CPU geremy condra <debatem1@gmail.com> - 2011-04-01 10:12 -0700
    Re: Python CPU Emile van Sebille <emile@fenx.com> - 2011-04-01 11:28 -0700
    Re: Python CPU Emile van Sebille <emile@fenx.com> - 2011-04-01 11:35 -0700
      Re: Python CPU John Nagle <nagle@animats.com> - 2011-04-01 12:18 -0700
    Re: Python CPU "BartC" <bc@freeuk.com> - 2011-04-02 23:06 +0100
      Re: Python CPU Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-04-03 04:03 +0000
    Re: Python CPU Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2011-04-03 12:10 +1200
      Re: Python CPU Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-04-03 04:01 +0000
        Re: Python CPU John Nagle <nagle@animats.com> - 2011-04-03 00:16 -0700
          Re: Python CPU Paul Rubin <no.email@nospam.invalid> - 2011-04-03 01:59 -0700
            Re: Python CPU Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2011-04-04 19:41 +1200
          Re: Python CPU Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2011-04-04 19:47 +1200
            Re: Python CPU Paul Rubin <no.email@nospam.invalid> - 2011-04-04 02:23 -0700
              Re: Python CPU Terry Reedy <tjreedy@udel.edu> - 2011-04-04 13:14 -0400
              Re: Python CPU Terry Reedy <tjreedy@udel.edu> - 2011-04-04 14:58 -0400
                Re: Python CPU Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2011-04-05 09:59 +1200
            Re: Python CPU geremy condra <debatem1@gmail.com> - 2011-04-04 09:36 -0700
              Re: Python CPU Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2011-04-05 10:05 +1200
            Re: Python CPU John Nagle <nagle@animats.com> - 2011-04-04 12:56 -0700
              Re: Python CPU Paul Rubin <no.email@nospam.invalid> - 2011-04-04 13:20 -0700
                Re: Python CPU Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2011-04-05 10:11 +1200
      Re: Python CPU Werner Thie <werner@thieprojects.ch> - 2011-04-03 17:44 +0200
        Re: Python CPU John Nagle <nagle@animats.com> - 2011-04-03 10:15 -0700
          Re: Python CPU Nobody <nobody@nowhere.com> - 2011-04-03 22:37 +0100
            Re: Python CPU Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2011-04-03 22:59 -0700

Page 1 of 2  [1] 2  Next page →

#2366 — Python CPU

Hi All,

I've heard of Java CPUs. Has anyone implemented a Python CPU in VHDL
or Verilog?

-Brad

[toc] | [next] | [standalone]

#2369

On Apr 1, 4:38 pm, Brad <hwfw...@gmail.com> wrote:
> Hi All,
>
> I've heard of Java CPUs.

And Forth CPUs as well, I suspect ;-)

> Has anyone implemented a Python CPU in VHDL
> or Verilog?
>

I don't think so - certainly not in recent memory. If you look at the
documentation for the python byte code, for example:

    http://docs.python.org/release/2.5.2/lib/bytecodes.html

you can see why. It starts off nicely enough, and then ...

    HTH
    J^n

[toc] | [prev] | [next] | [standalone]

#2371

On Fri, 01 Apr 2011 08:38:27 -0700, Brad wrote:

> I've heard of Java CPUs. Has anyone implemented a Python CPU in VHDL
> or Verilog?

Java is a statically-typed language which makes a distinction between
primitive types (bool, int, double, etc) and objects. Python is a
dynamically-typed language which makes no such distinction. Even something
as simple as "a + b" can be a primitive addition, a bigint addition, a
call to a.__add__(b) or a call to b.__radd__(a), depending upon the values
of a and b (which can differ for different invocations of the same code).

This is one of the main reasons that statically-typed languages exist, and
are used for most production software.

[toc] | [prev] | [next] | [standalone]

#2373

Nobody, 01.04.2011 18:52:
> Java is a statically-typed language which makes a distinction between
> primitive types (bool, int, double, etc) and objects. Python is a
> dynamically-typed language which makes no such distinction. Even something
> as simple as "a + b" can be a primitive addition, a bigint addition, a
> call to a.__add__(b) or a call to b.__radd__(a), depending upon the values
> of a and b (which can differ for different invocations of the same code).
>
> This is one of the main reasons that statically-typed languages exist, and
> are used for most production software.

I doubt that the reason they are "used for most production software" is a 
technical one.

Stefan

[toc] | [prev] | [next] | [standalone]

#2376

On Fri, Apr 1, 2011 at 10:00 AM, Stefan Behnel <stefan_ml@behnel.de> wrote:
> Nobody, 01.04.2011 18:52:
>>
>> Java is a statically-typed language which makes a distinction between
>> primitive types (bool, int, double, etc) and objects. Python is a
>> dynamically-typed language which makes no such distinction. Even something
>> as simple as "a + b" can be a primitive addition, a bigint addition, a
>> call to a.__add__(b) or a call to b.__radd__(a), depending upon the values
>> of a and b (which can differ for different invocations of the same code).
>>
>> This is one of the main reasons that statically-typed languages exist, and
>> are used for most production software.
>
> I doubt that the reason they are "used for most production software" is a
> technical one.

I also suspect that there's some confusion between duck typing and
typelessness going on here.

Geremy Condra

[toc] | [prev] | [next] | [standalone]

#2378

On 4/1/2011 8:38 AM Brad said...
> Hi All,
>
> I've heard of Java CPUs. Has anyone implemented a Python CPU in VHDL
> or Verilog?
>
> -Brad


http://code.google.com/p/python-on-a-chip/

Emile

[toc] | [prev] | [next] | [standalone]

#2379

On 4/1/2011 11:28 AM Emile van Sebille said...
> On 4/1/2011 8:38 AM Brad said...
>> Hi All,
>>
>> I've heard of Java CPUs. Has anyone implemented a Python CPU in VHDL
>> or Verilog?
>>
>> -Brad
>
>
> http://code.google.com/p/python-on-a-chip/

Sorry - wrong url in the cut'n paste buffer -

   http://tsheffler.com/software/python/

>
> Emile
>
>

[toc] | [prev] | [next] | [standalone]

#2383

On 4/1/2011 11:35 AM, Emile van Sebille wrote:
> On 4/1/2011 11:28 AM Emile van Sebille said...
>> On 4/1/2011 8:38 AM Brad said...
>>> Hi All,
>>>
>>> I've heard of Java CPUs. Has anyone implemented a Python CPU in VHDL
>>> or Verilog?
>>>
>>> -Brad
>>
>>
>> http://code.google.com/p/python-on-a-chip/
>
> Sorry - wrong url in the cut'n paste buffer -
>
> http://tsheffler.com/software/python/
>
>>
>> Emile

    Neither of those is a hardware implementation of Python.
"Python on a chip" is a small Python-subset interpreter for
microcontrollers.  That could be useful if it's not too slow.

    Sheffler's software is a means for controlling and extending
Verilog simulations in Python.  (Often, you're simulating some
hardware at the gate level which interfaces with other existing
hardware, say a disk, which can be simulated at a much coarser
level.  Being able to write the simulator for the external devices
in Python is useful.)

				John Nagle

[toc] | [prev] | [next] | [standalone]

#2473

"Brad" <hwfwguy@gmail.com> wrote in message 
news:01bd055b-631d-45f0-90a7-229da4a9a362@t19g2000prd.googlegroups.com...
> Hi All,
>
> I've heard of Java CPUs. Has anyone implemented a Python CPU in VHDL
> or Verilog?

For what purpose, improved performance? In that case, there's still plenty 
of scope for that on conventional CPUs.

The Java VM is fairly low level (I would guess, not being too familiar with 
it), while the Python VM seems much higher level and awkward to implement 
directly in hardware.

I don't think it's impossible, but the benefits probably would not match 
those of improving, say, Cpython on conventional hardware. And if a Python 
CPU couldn't also run non-Python code efficiently, then on a typical 
workload with mixed languages, it could be much slower!

However, wasn't there a Python version that used JVM? Perhaps that might run 
on a Java CPU, and it would be interesting to see how well it works.

-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

#2494

On Sat, 02 Apr 2011 23:06:52 +0100, BartC wrote:

> However, wasn't there a Python version that used JVM? Perhaps that might
> run on a Java CPU, and it would be interesting to see how well it works.

Not only *was* there one, but there still is: Jython. Jython is one of 
the "Big Three" Python implementations:

* CPython (the one you're probably using)
* Jython (Python on Java)
* IronPython (Python on .Net)

with PyPy (Python on Python) catching up.

http://www.jython.org/


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#2477

Brad wrote:

> I've heard of Java CPUs. Has anyone implemented a Python CPU in VHDL
> or Verilog?

Not that I know of.

I've had thoughts about designing one, just for the exercise.

It's doubtful whether such a thing would ever be of practical
use. Without as much money as Intel has to throw at CPU
development, it's likely that a Python chip would always be
slower and more expensive than an off-the-shelf CPU running
a tightly-coded interpreter.

It could be fun to speculate on what a Python CPU might
look like, though.

-- 
Greg

[toc] | [prev] | [next] | [standalone]

#2493

On Sun, 03 Apr 2011 12:10:35 +1200, Gregory Ewing wrote:

> Brad wrote:
> 
>> I've heard of Java CPUs. Has anyone implemented a Python CPU in VHDL or
>> Verilog?
> 
> Not that I know of.
> 
> I've had thoughts about designing one, just for the exercise.
> 
> It's doubtful whether such a thing would ever be of practical use.
> Without as much money as Intel has to throw at CPU development, it's
> likely that a Python chip would always be slower and more expensive than
> an off-the-shelf CPU running a tightly-coded interpreter.

I recall back in the late 80s or early 90s, Apple and Texas Instruments 
collaborated to build a dual-CPU Lisp machine. I don't remember all the 
details, but it was an Apple Macintosh II with a second CPU running (I 
think) a TI Explorer (possibly on a Nubus card?), with an integration 
layer that let the two hardware machines talk to each other. It was dual-
branded Apple and TI.

It was a major flop. It was released around the time that general purpose 
CPUs started to get fast enough to run Lisp code faster than a custom-
made Lisp CPU could. I don't remember the actual pricing, so I'm going to 
make it up... you got better performance from a standard Mac II with 
software Lisp for (say) $12,000 than you got with a dedicated Lisp 
machine for (say) $20,000.

(These are vaguely recalled 1980s prices. I'm assuming $10K for a Mac II 
and $2K for the Lisp compiler. Of course these days a $400 entry level PC 
is far more powerful than a Mac II.)

There were also Forth chips, which let you run Forth in hardware. I 
believe they were much faster than Forth in software, but were killed by 
the falling popularity of Forth.


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#2508

On 4/2/2011 9:01 PM, Steven D'Aprano wrote:
> There were also Forth chips, which let you run Forth in hardware. I
> believe they were much faster than Forth in software, but were killed by
> the falling popularity of Forth.

     The Forth chips were cute, and got more done with fewer gates than
almost anything else.  But that didn't matter for long.
Willow Garage has a custom Forth chip they use in their Ethernet
cameras, but it's really a FPGA.

     A tagged machine might make Python faster.  You could have
unboxed ints and floats, yet still allow values of other types,
with the hardware tagging helping with dispatch.   But it probably
wouldn't help all that much.  It didn't in the LISP machines.

					John Nagle

[toc] | [prev] | [next] | [standalone]

#2515

John Nagle <nagle@animats.com> writes:
>     The Forth chips were cute, and got more done with fewer gates than
> almost anything else.  But that didn't matter for long.
> Willow Garage has a custom Forth chip they use in their Ethernet
> cameras, but it's really a FPGA.

You can order 144-core Forth chips right now,

   http://greenarrays.com/home/products/index.html

They are asynchronous cores running at around 700 mhz, so you get an
astounding amount of raw compute power per watt and per dollar.  But for
me at least, it's not that easy to figure out applications where their
weird architecture fits well.

[toc] | [prev] | [next] | [standalone]

#2555

Paul Rubin wrote:

> You can order 144-core Forth chips right now,
> 
>    http://greenarrays.com/home/products/index.html
> 
> They are asynchronous cores running at around 700 mhz, so you get an
> astounding amount of raw compute power per watt and per dollar.  But for
> me at least, it's not that easy to figure out applications where their
> weird architecture fits well.

Hmmm... Maybe compiling Python to Forth would make sense?-)

-- 
Greg

[toc] | [prev] | [next] | [standalone]

#2556

John Nagle wrote:

>     A tagged machine might make Python faster.  You could have
> unboxed ints and floats, yet still allow values of other types,
> with the hardware tagging helping with dispatch.   But it probably
> wouldn't help all that much.  It didn't in the LISP machines.

What might help more is having bytecodes that operate on
arrays of unboxed types -- numpy acceleration in hardware.

-- 
Greg

[toc] | [prev] | [next] | [standalone]

#2559

Gregory Ewing <greg.ewing@canterbury.ac.nz> writes:
> What might help more is having bytecodes that operate on
> arrays of unboxed types -- numpy acceleration in hardware.

That is an interesting idea as an array or functools module patch.
Basically a way to map or fold arbitrary functions over arrays, with a
few obvious optimizations to avoid refcount churning.  It could have
helped with a number of things I've done over the years.

[toc] | [prev] | [next] | [standalone]

#2578

On 4/4/2011 5:23 AM, Paul Rubin wrote:
> Gregory Ewing<greg.ewing@canterbury.ac.nz>  writes:
>> What might help more is having bytecodes that operate on
>> arrays of unboxed types -- numpy acceleration in hardware.
>
> That is an interesting idea as an array or functools module patch.
> Basically a way to map or fold arbitrary functions over arrays, with a
> few obvious optimizations to avoid refcount churning.  It could have
> helped with a number of things I've done over the years.

For map, I presume you are thinking of an array.map(func) in system code 
(C for CPython) equivalent to

def map(self,func):
   for i,ob in enumerate(self):
     self[i] = func(ob)

The question is whether it would be enough faster. Of course, what would 
really be needed for speed are wrapped system-coded funcs that map would 
recognize and pass and received unboxed array units to and from. At that 
point, we just about invented 1-D numpy ;-).

I have always thought the array was underutilized, but I see now that it 
only offers Python code space saving at a cost of interconversion time. 
To be really useful, arrays of unboxed data, like strings and bytes, 
need system-coded functions that directly operate on the unboxed data, 
like strings and bytes have. Array comes with a few, but very few, 
generic sequence methods, like .count(x) (a special-case of reduction).

-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#2582

On 4/4/2011 1:14 PM, Terry Reedy wrote:
> On 4/4/2011 5:23 AM, Paul Rubin wrote:
>> Gregory Ewing<greg.ewing@canterbury.ac.nz> writes:
>>> What might help more is having bytecodes that operate on
>>> arrays of unboxed types -- numpy acceleration in hardware.
>>
>> That is an interesting idea as an array or functools module patch.
>> Basically a way to map or fold arbitrary functions over arrays, with a
>> few obvious optimizations to avoid refcount churning. It could have
>> helped with a number of things I've done over the years.
>
> For map, I presume you are thinking of an array.map(func) in system code
> (C for CPython) equivalent to
>
> def map(self,func):
> for i,ob in enumerate(self):
> self[i] = func(ob)
>
> The question is whether it would be enough faster. Of course, what would
> really be needed for speed are wrapped system-coded funcs that map would
> recognize and pass and received unboxed array units to and from. At that
> point, we just about invented 1-D numpy ;-).
>
> I have always thought the array was underutilized, but I see now that it
> only offers Python code space saving at a cost of interconversion time.
> To be really useful, arrays of unboxed data, like strings and bytes,
> need system-coded functions that directly operate on the unboxed data,
> like strings and bytes have. Array comes with a few, but very few,
> generic sequence methods, like .count(x) (a special-case of reduction).

After posting this, I realized that ctypes makes it easy to find and 
wrap functions in a shared library as a Python object (possibly with 
parameter annotations) that could be passed to array.map, etc. No 
swigging needed, which is harder than writing simple C functions. So a 
small extension to array with .map, .filter, .reduce, and a wrapper 
class would be more useful than I thought.


-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#2603

Terry Reedy wrote:
> So a 
> small extension to array with .map, .filter, .reduce, and a wrapper 
> class would be more useful than I thought.

Also useful would be some functions for doing elementwise
operations between arrays. Sometimes you'd like to just do
a bit of vector arithmetic, and pulling in the whole of
numpy as a dependency seems like overkill.

-- 
Greg

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.python

csiph-web