2's complement conversion. Is this right?

Bob Greschke bob at passcal.nmt.edu
Sat Apr 19 17:24:32 EDT 2008


On 2008-04-18 23:35:12 -0600, Ivan Illarionov <ivan.illarionov at gmail.com> said:

> On Sat, 19 Apr 2008 04:45:54 +0000, Ivan Illarionov wrote:
> 
>> On Fri, 18 Apr 2008 22:30:45 -0500, Grant Edwards wrote:
>> 
>>> On 2008-04-18, Bob Greschke <bob at passcal.nmt.edu> wrote:
>>> 
>>>> However, in playing around with your suggestion and Grant's code I've
>>>> found that the struct stuff is WAY slower than doing something like
>>>> this
>>>> 
>>>> Value = (ord(Buf[s])*65536)+(ord(Buf[s+1])*256)+ord(Buf[s+2]) if
>>>> Value
>>>>> = 0x800000:
>>>> Value -= 0x1000000
>>>> 
>>>> This is almost twice as fast just sitting here grinding through a few
>>>> hundred thousand conversions (like 3sec vs. ~5secs just counting on my
>>>> fingers - on an old Sun...it's a bit slow).  Replacing *65536 with
>>>> <<16 and *256 with <<8 might even be a little faster, but it's too
>>>> close to call without really profiling it.
>>> 
>>> I didn't know speed was important.  This might be a little faster
>>> (depending on hardware):
>>> 
>>> Value = (ord(Buf[s])<<16) | (ord(Buf[s+1])<<8) | ord(Buf[s+2])
>>> 
>>> It also makes the intention a bit more obvious (at least to me).
>>> 
>>> A decent C compiler will recognize that <<16 and <<8 are special and
>>> just move bytes around rather than actually doing shifts.  I doubt the
>>> Python compiler does optimizations like that, but shifts are still
>>> usually faster than multiplies (though, again, a good compiler will
>>> recognize that multiplying by 65536 is the same as shifting by 16 and
>>> just move bytes around).
>> 
>> So why not put it in C extension?
>> 
>> It's easier than most people think:
>> 
>> <code>
>> from3bytes.c
>> ============
>> #include <Python.h>
>> 
>> PyObject*
>> from3bytes(PyObject* self, PyObject* args) {
>> const char * s;
>> int len;
>> if (!PyArg_ParseTuple(args, "s#", &s, &len))
>> return NULL;
>> long n = (s[0]<<16) | (s[1]<<8) | s[2]; if (n >= 0x800000)
>> n -= 0x1000000;
>> return PyInt_FromLong(n);
>> }
>> 
>> static PyMethodDef functions[] = {
>> {"from3bytes",    (PyCFunction)from3bytes, METH_VARARGS}, {NULL,
>> NULL, 0, NULL},
>> };
>> 
>> 
>> DL_EXPORT(void)
>> init_from3bytes(void)
>> {
>> Py_InitModule("_from3bytes", functions);
>> }
>> 
>> buildme.py
>> ==========
>> import os
>> import sys
>> from distutils.core import Extension, setup
>> 
>> os.chdir(os.path.dirname(os.path.abspath(__file__))) sys.argv =
>> [sys.argv[0], 'build_ext', '-i'] setup(ext_modules =
>> [Extension('_from3bytes', ['from3bytes.c'])]) </code>
>> 
>> 'python buildme.py' will create '_from3bytes.so' file 'from _from3bytes
>> import from3bytes' will import C-optimized function
>> 
>> Hope this helps.
> 
> Sorry,
> the right code should be:
> 
> PyObject* from3bytes(PyObject* self, PyObject* args)
> {
>     const char * s;
>     int len;
>     if (!PyArg_ParseTuple(args, "s#", &s, &len))
>         return NULL;
>         long n = ((((unsigned char)s[0])<<16) | (((unsigned char)s[1])<<8) |
> ((unsigned char)s[2]));
>     if (n >= 0x800000)
>         n -= 0x1000000;
>     return PyInt_FromLong(n);
> }

No thanks.  Being able to alter and install these programs on whatever 
computer they are installed on is more important than speed.  I went 
down the C-extension path years ago and it turned into a big mess.  
Everything has to run on Sun's, Mac's, Linux and Windows without any 
major hassels if they have to be changed.  I can't reley on everything 
the program needs to be rebuilt being installed beyond Python and 
Tkinter (and pySerial and PIL for a couple of programs), which they 
need to run.  So no compiling and everything is in one file, in case a 
new version has to be upgraded by a user by emailing it to them while 
they're sitting on some mountain in Tibet.  Just unzip, stick the .py 
somewhere logical, (usually) double-click, and they are off and running.

Bob





More information about the Python-list mailing list