Real-world Python code 700 times slower than C

[Skip Montanaro]

    Chris> However... I have little knowledge if the internals of Numpy, but
    Chris> from working with the API, it appears that the data is in one big
    Chris> char[] array, so the malloc may not have known that the data was
    Chris> going to be used as doubles, so it may not have bothered to
    Chris> allign it properly.  Perhaps it is time to cross post this to the
    Chris> Numeric group.

I don't think that's a problem, especially now that you've fessed up that
you're using RedHat 6.0 (which implies you're using gcc and a decent version
of malloc).  All malloc's have to be prepared to hand back a chunk of memory
suitable for any use (array of doubles or structs, for example).  Generally,
that means all allocations will be aligned according to the most picky
datatype, which is often double precision floating point.  As Cliff Wells
pointed out in a private email, there are at least some Windows/VC++
combinations where this doesn't hold, but I seriously doubt that's the case
here.

Tim or one of the Numeric gang can certainly answer more authoritatively
than I can, but I will offer my latest foray into the many uses of PyInline:

    #!/usr/bin/env python

    import PyInline

    m = PyInline.build(code="""
    void
    Alloc()
    {
        int i;
        char c1;
        float f;
        char c2;
        double d;
        void *v;

        fprintf(stderr, "type            addr        %8\n");
        fprintf(stderr, "------------------------------\n");
        fprintf(stderr, "int:            0x%x (%d)\n", &i, ((unsigned long int)&i)%8);
        fprintf(stderr, "char1:          0x%x (%d)\n", &c1, ((unsigned long int)&c1)%8);
        fprintf(stderr, "float:          0x%x (%d)\n", &f, ((unsigned long int)&f)%8);
        fprintf(stderr, "char2:          0x%x (%d)\n", &c2, ((unsigned long int)&c2)%8);
        fprintf(stderr, "double:         0x%x (%d)\n", &d, ((unsigned long int)&d)%8);
        fprintf(stderr, "void*:          0x%x (%d)\n", &v, ((unsigned long int)&v)%8);
        v = malloc(1);
        fprintf(stderr, "malloc output:  0x%x (%d)\n", v,
                        ((unsigned long int)v)%8);
        free(v);
    }
    """, language="C")

    m.Alloc()

On my Mandrake/gcc system executing "python malloc.py" prints:

    type            addr        %8
    ------------------------------
    int:            0xbffff4ac (4)
    char1:          0xbffff4ab (3)
    float:          0xbffff4a4 (4)
    char2:          0xbffff4a3 (3)
    double:         0xbffff498 (0)
    void*:          0xbffff494 (4)
    malloc output:  0x81eafc0 (0)

demonstrating that malloc output is aligned appropriate for doubles.

-- 
Skip Montanaro (skip at pobox.com - http://www.mojam.com/)