3 ms·
All those features have a cost that, in a performance oriented setting, require restricted the code to a subset of Julia that matches what the hardware is fast
by marmaduke 6y ago
All those features have a cost that, in a performance oriented setting, require restricted the code to a subset of Julia that matches what the hardware is fast at.
- deleted 6y ago[deleted]
- dklend122 6y agoNo, that's not true. I specifically mentioned features that can easily be made zero cost on both CPU and GPU targets. In fact, those aren't special features and there is no other subset. Those are the core abstractions on which everything in Julia, down to primitive types and wrappers for llvm intrinsics are built. Without them you wouldn't have Julia. Julia's GPU ecosystem wouldn't be where it is with just one or two people maintaining it without being able to reuse those features to plug into existing machinery.
- DNF2 6y agoWhere are you getting this from? None of those features have a performance cost, if used according to some simple guidelines. In fact, multiple dispatch is essential to get good performance, abstract types have a cost if explicitly used inside struct definitions, but that's why you use parametric types, and abstract types do not have a cost in function signatures. Macros are expanded at compile-time, and at least have no runtime cost, in fact they are often used for improved performance. I think there's some fundamental misunderstanding going on here, but I'm not sure what it is. Or do you mean to say that if it is possible to write slow code in a language, then only a subset of that language has good performance? If that is the case, I don't know how to respond.