On May 16, 11:24 am, "inhahe" <[EMAIL PROTECTED]> wrote: > "D'Arcy J.M. Cain" <[EMAIL PROTECTED]> wrote in messagenews:[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.
The Society for Inherited Metabolic Disorders? Why wouldn't the compilers support it? It's part of the x86 architexture, isn't it? -- http://mail.python.org/mailman/listinfo/python-list
