On May 17, 2008, at 2:22 PM, Norman Ramsey wrote: >>> ell i definitely need to make a python extension, although maybe i >>> could >> make a static library with c-- and link it to a c++ program and >> make that >> into a dll. i might just use c++ with inline asm. i'm just >> looking around >> at this point. i'm not sure which of the SIMD extensions i need >> yet, i'd >> have to read about them and see their advantages. i think there's a >> tradeoff between advantages of using a newer version of it and how >> many >> systems it's available on and how much work i want to do to support X >> different versions of it. > > I admit freely that I don't understand why there are so many different > SIMD extensions. But I'm definitely willing to look at SIMD > constructs for C-- with an eye to letting the compiler take advantage > of what's available. Ideally you could write SIMD programs in C-- > and let the compiler do the rest. > > Of course, this is a nontrivial task I'm proposing: you don't want to > just write loops and hope that some clever optimization turns them > into SIMD; you actually want to specify SIMD in the source code > somehow. I think there's an interesting problem lurking here. > The difference between SIMD and PIC is that I think with SIMD it > should be possible to make progress quickly.
If you are interested in doing this, I strongly suggest looking into LLVM. This is a solved problem. I'm not sure what your difficulty with PIC is, but SIMD is generally much harder if you would like to be multiple architectures. The various architectures (e.g. Altivec vs SIMD) have sometimes widely different capabilities and each individual architecture is horribly non-orthogonal. -Chris _______________________________________________ Cminusminus mailing list [email protected] https://cminusminus.org/mailman/listinfo/cminusminus
