> > Well I was rather thinking of making a Swift-only library (at least at first) > but that would also be available for other platforms e.g Linux or maybe some > day on Windows => also working with reduced performance without the > Accelerator Framework but leveraging it on Apple Platforms (and possibly > leveraging others on the other platforms). This said I am open to discussion > on this... but having a very nice syntax for swift and having an close to > one-to-one equivalent also for Objective-C will probably add quite some > difficulties. >
While still very much in its infancy, just to add the libraries out there, there is: https://github.com/abeschneider/stem <https://github.com/abeschneider/stem> . However, the library currently suffers from design issues related to dispatching correctly from generic functions. That said, I was able to recreate a large part of the Numpy functionality while allowing the ability to leverage the Accelerator Framework and OpenCL/CUDA. > > again, with the obvious implementation, this wastes space for temporaries > > and results in extraneous passes through the data. It is often *possible* > > to solve these issues (at least for some the most common cases) by > > producing proxy objects that can fuse loops, but that gets very messy very > > fast, and it’s ton of work to support all the interesting cases. > > This is clear to me and to be honest with you I am not really sure of the > best strategy to make this. The most successful method I’ve seen for dealing with this is let the user write what is most natural first (allowing for temporaries) but provide a path to optimize (using in-place operations). While expression trees can automate this for the user, it also has the potential for being much more difficult to debug and may not be as optimal as a hand-crafted expression. > > I don't think that the primary target for the library should be to deliver > the highest performance possible. > => People who do need that level of performance would still need to analyze > and optimize their code by themselves and/or directly call the Acceleration > Framework or other specialized libraries. > > What I would like to reach instead is rather what I would call "the highest > usability possible with decent performance". Some programmers will be > satisfied with the level of performance and will enjoy the readability and > maintainability of the code based of the library, whereas other will go for > more performant libraries (and that is perfectly fine!). Actually, I would > even expect later that some of those who belong to the latter category will > start experimenting with the easy but less performant library (lets call it > here "easy maths library") and optimize their code based on a high > performance library only in a second step. If you can define your operations at the right granularity you can write really optimized Accelerate/OpenCL/CUDA code for the low level parts and string it together with less optimize code. > > My idea of a possibly pragmatic roadmap (which can be followed in that order) > to make such a library almost from scratch with the long-term goal of being > quite performant but primarily very easy to use could be: > > 1) think about the integration to the language, the syntax, the high-level > user documentation, etc. and demonstrate all this based on a relatively low > performance implementation > > 2) generate a collection a typical operations where the low-level libraries > offer very nice performance or where a clever handling of the temporary > variables is possible For (1) and (2), it’s worth taking a look at what libraries exist already. People have spent a lot of time organizing and re-organizing these. While not perfect, Numpy has become one of the most successful matrix libraries out there.
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
