Hi! rosko37ï¼ gmail.com wrote: > Certainly a means of fixing the "two language problem", if it works, would be > a great thing. However, the SPy documentation I saw doesn't address what I > see as some of the main issues that lead to this problem. > > The fact that Python doesn't run like C (or Rust, or Fortran) is only partly > to do with dynamic typing. It also has to do with the ability for the > programmer to reason well about aspects of the algorithm like memory layouts > (including things like row-major vs. column-major ordering and how many > levels of pointer indirection exist in an object), cache "friendliness", the > cost of operations, etc.
all of this is totally in scope for SPy. The idea is to provide low-level mechanisms to write this kind of code (which are then translated to the equivalent C), on top of which to build higher level zero costs abstractions to hide these details from the final user. A good example of this pattern in action is the implementation of `list`, whch is in SPy itself; here you can see that the underlying data is basically a C array, but then it uses SPy-specific features e.g. to statically dispatch the `__getitem__` to the "index version" or to the "slice version": https://github.com/spylang/spy/blob/1c6ad6bdb59541c44b43a55830b2ff6b8c03427c/stdlib/_list.spy#L17-L51 These low-level features are accessed by using the `unsafe` module. Currently you can use unsafe features "freely", meaning that the end user is potentially able to shoot themselves in the foot, but the long term plan is that "unsafe" features can be accessed only in certain specific areas of code clearly labeled as such. This is similar to what already happens in Python, where there "unsafe" features are "clearly labeled" as C code :). > It's not JUST numerical algorithms that this applies to. For instance, in > Python code it's very common to pass what are essentially structs as > dictionaries, where the field names are keys. To make them C-like in > performance (and memory usage), these should decay to actual structs, which > of course requires that queries/"indices" to these dicts are known at compile > time in all instances, i.e. are not the values of variables. again something which is fully supported by SPy. See e.g. the implementation of `tuple` in `stdlib/_tuple.spy`: https://github.com/spylang/spy/blob/1c6ad6bdb59541c44b43a55830b2ff6b8c03427c/stdlib/_tuple.spy#L5-L53 Tuples are translated into the equivalent C struct. E.g. `tuple[i32, str]` is translated into `struct _tup { int32_t _item0; spy_str *_item1; }`. Then there is "SPy blue magic" to translate `__getitem__(0)` into a direct `._item0` field access. It will totally be possible to do the same for dicts whose set of keys are known at compile time. _______________________________________________ NumPy-Discussion mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3//lists/numpy-discussion.python.org Member address: [email protected]
