Also, don't forget that there's a big difference between *being able to* use something like pragmas to squeeze out performance, and *having to*.
We're already exposing some stuff that potentially make things way faster if you can promise stuff that the compiler can't, e.g. @inbounds. @aligned would fit right in there, but being able to do that is not an excuse to not make Julia so fast without it that most users don't need to even know about it. My 50¢... // T On Friday, March 20, 2015 at 9:49:40 AM UTC+1, Stefan Karpinski wrote: > > I agree that one doesn't want to expose all of what C + pragmas + inline > assembly can do at the higher level, but I suspect there's some set of > functionality that can let you do most of the work at the higher level. But > we'll see how it pans out. Maybe the high-level functionality is a set of > data structures or constructs that cover the range in some sense. > > On Fri, Mar 20, 2015 at 9:06 AM, Gunnar Farnebäck <[email protected] > <javascript:>> wrote: > >> Den fredag 20 mars 2015 kl. 05:36:15 UTC+1 skrev Kiran Pamnany: >> >>> Hey Stefan, >>> >>> >>>> Depending on how well Julia-generated code performs, some important >>>>> concurrent data structures might be better implemented in C and wrapped. >>>> >>>> >>>> I would argue that until we can implement efficient concurrent data >>>> structures in pure Julia, the work isn't complete. It's ok to use C code >>>> as >>>> an interim solution while we're developing this, but in the longer term, >>>> we >>>> should not be forced to rely on C to write libraries. >>>> >>> >>> Think of the implementations in C as though we're dropping into inline >>> assembly for maximizing performance. In actual fact, using alignment >>> directives, padding, SIMD intrinsics, or specialized load/store >>> instructions _is_ pretty much assembly. I don't see value in adding this >>> sort of architecture-specific explicit control to Julia--it negates the >>> high-level, high-productivity aspect if you have to throw in pragmas like >>> assume_aligned in your code for performance reasons. And if you go down >>> that road, then you're competing with C. >>> >>> On the contrary I see an enormous value in being able to do what's >> effectively inline assembly within an environment with the metaprogramming >> capabilities of Julia and seamless integration with the parts of the code >> that are not quite as performance critical. >> >> >
