FeedaMail: Comments for Sutter’s Mill

	Comments for Sutter's Mill
	(Sponsor this newsletter) Comment on Trip report: Spring ISO C++ meeting by David Greene SIMD types is a very bad idea. Use of such types locks the code into a particular style of vectorization, making it less (performance) portable. It’s much better to add bits of language to allow the user to tell the compiler what is safe and/or profitable. For pointer-heavy code, a directive to tell the compiler to ignore potential data dependencies is very helpful (in addition, insert request for something like “restrict,” but better, here). Compilers have all kinds of transformations to improve cache usage, rework loops for better parallel efficiency, etc. Do not constrain the compiler by forcing it to vectorize a particular loop in a particular way. Tell the compiler what is safe and hint at what is profitable and let it do it’s work. It’s the compiler’s job to map to hardware, not the user’s. The original Intel paper on this cited cache utilization as a motivating example, with the valarray “operate on all elements in one operation before doing the next” semantics being blamed. Fortran array syntax has similar semantics and vectorizing compilers have got along with it just fine. C++’s real handicap with respect to parallelization is ambiguous pointers. Providing tools to eliminate that problem will go a long way toward improving parallelization. Read More »
	(Sponsor this newsletter)
	Delievered to you by Feedamail. Unsubscribe