I don't know about the internals of current activities in Python, but I know where you can find reams of array code in C, FORTRAN, and other languages in 3D graphics libraries (4 x 4 matrix multiplication especially), multimedia compression and decompression, cryptography (particularly RSA exponentiation, but also elliptic curve cryptography, ssh key exchange, and others), audio and image processing (lots of convolutions), font rendering (quadratic and cubic splines), and other computationally intensive domains. The more we do on this front now, the better for the older students when they come to modeling, numeric integration, linear programming, linear algebra, computational molecular biology, and so on and on and on.
I believe the GNU compilers use a common intermediate format and code generator for a variety of languages. Ah, here we go. http://gcc.gnu.org/ "The GNU Compiler Collection includes front ends for C, C++, Objective-C, Fortran, Java, and Ada, as well as libraries for these languages (libstdc++, libgcj,...)." There are over 1,000 hits on Geode in their archive. For example, -mtune=cpu-type ... geode Embedded AMD CPU with MMX and 3dNOW! instruction set support. While picking a specific cpu-type will schedule things appropriately for that particular chip, the compiler will not generate any code that does not run on the i386 without the -march=cpu-type option being used. ... -march=cpu-type Generate instructions for the machine type cpu-type. The choices for cpu-type are the same as for -mtune. Moreover, specifying -march=cpu-type implies -mtune=cpu-type. Interesting. It appears that much of the necessary work has been done, and we could get fairly good results if we just set up a small compile farm and comb through our current code base. With plenty of regression testing, of course. I have machine time to spare, and would be happy to recruit at the local LUGs. Or we could talk to distributed.net and BOINC. Much more performance would remain to be wrung out by rewriting small sections of some kinds of code, and presumably the true wizards could find more code generation optimizations than we have yet seen here. Does anybody know how we handle signal processing in the Tamtam software synth? The Fast Fourier Transforms for going from time domain to frequency domain in the data visualization activity are a prime target. It's all multiply-accumulate except for the bit twiddling. What is the theoretical performance of the Geode LX for various kinds of arithmetic? What performance are we getting? On 10/29/07, Brian Carnes <[EMAIL PROTECTED]> wrote: > The developers page on the wiki > (http://wiki.laptop.org/go/Developers_program) mentions: > > "compiler optimization: if you are a compiler wizard, we understand that > the Geode lacks a specific back end code scheduler, which limits > performance, particularly FP performance. We'd love to see work go on in > this area which would help everyone." > > > What aspects of this issue/request for help are still open? I'll go take > a look at the OLPC build system tonight to see what is being used (late > versions of GCC do have some Geode -mtune/-march modes), but would love to > be hooked into whatever project is addressing this > > ...Or start my own project if I'm the first to step to the plate on this > issue. If anyone knows any particularly lengthy floating-point dominated > operations in the current software, let me know and we'll use them as our > metric for improvement. > > Thanks, > > Brian > > > _______________________________________________ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel > -- Edward Cherlin Earth Treasury: End Poverty at a Profit http://wiki.laptop.org/go/Earth_Treasury Sustainable MBA student Presidio School of Management _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
