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]> 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. > >
