"D'Arcy J.M. Cain" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > 2. Once the code is functioning, benchmark it and find the > bottlenecks. Replace the problem methods with a C extension. Refactor > (and check your unit tests again) if needed to break out the problem > areas into as small a piece as possible.
There's probably only 2 or 3 basic algorithms that will need to have all that speed. > > 3. If it is still slow, embed some assembler where it is slowing down. > I won't know if the assembler is faster until I embed it, and if I'm going to do that I might as well use it. Although it's true I'd only have to embed it for one system to see (more or less). > >> For portability, I'd simply write different asm routines for different >> systems. How wide a variety of systems I'd support I don't know. As a >> bare >> minimum, 32-bit x86, 64-bit x86, and one or more of their available forms >> of >> SIMD. > > Even on the same processor you may have different assemblers depending > on the OS. yeah I don't know much about that, I was figuring perhaps I could limit the assembler parts / methodology to something I could write generically enough.. and if all else fails write for the other OS's or only support windows. also I think I should be using SIMD of some sort, and I'm not sure but I highly doubt C++ compilers support SIMD. -- http://mail.python.org/mailman/listinfo/python-list
