we can mull over one example to see if there's anything inspriational think outside the box here even to the point of applying a preprocessing step e.g., comment-like hints in the code for a preprocessor
why a preprocessor? all of the esoteric goop can be restricted to one spot including e.g., the extra speedup that uses the magic X instruction on processor Y for compiler Z and the original code is intact except for the hints I don't know if that's workable but that's the kind of approach that is readable and maintainable *and* when the compiler optimizers finally catch up can be eliminated from the source with sed On Mon, 21 May 2012 09:57:37 +0200 Irek Szczesniak wrote: > On Tue, May 1, 2012 at 7:22 AM, Glenn Fowler <[email protected]> wrote: > > > > I appreciate the effort you put into coding the prefetch example > > but there's no way we would sprinkle #ifdef'd code like that across ast > > it would be a maintenance headache > > and what will the next speedup dujour do to the code > > this feels really close to coding in asm > > (although we have done manual unrolling and asm in a few spots) > Glenn, can we make a bargain where you accept the patch when Roland > removes the #ifdef and does some other restructuring? We've tested a > newer patch from Roland and found that every platform we benchmarked > (IA64, x86-64/AMD, x86-64/Sandybridge, x86-32, ARM, MIPS64, SPARC64, > Oracle Ultrasparc T2/T3/T3+) show significant performance gains and I > start to think it is worth taking, even if the design highlights the > 'portable assembler' heritage of the C language :) > Irek _______________________________________________ ast-developers mailing list [email protected] https://mailman.research.att.com/mailman/listinfo/ast-developers
