[swift-evolution] Pitch: (Almost) std libs
dturnbull at gmail.com
Tue Jan 26 20:49:16 CST 2016
Functions in a module go through dynamic dispatch. Operators are functions.
So multiplying two complex numbers won't get inlined. The stdlib uses
internal tricks so what appears as a module you import is available to be
specialized and inlined.
To see this in action, try the CubeWorld demo from here:
Then change it so the math libraries aren't modules (move the files, delete
the import statements). On my system, CPU drops from 60% to 6%. It's also
the difference between 150 cubes and 1200 cubes at 60 fps. Make sure you
turn on WMO.
I'm told it won't always be this way. But it is today.
On Tue, Jan 26, 2016 at 6:18 PM, Trent Nadeau <tanadeau at gmail.com> wrote:
> I'm confused. Why would you get dynamic dispatch for a complex number just
> because it's in another module? I think a complex number would always be a
> struct so everything would be inline to the storage on the stack, and
> there's no inheritance so no vtable.
> On Tue, Jan 26, 2016 at 7:46 PM, David Turnbull via swift-evolution <
> swift-evolution at swift.org> wrote:
>> Rust has a Nursery. C++ gets a Boost. Swift is a Breeze? The only problem
>> is that a lot of stdlib-like things aren't suitable for modules.
>> For example, it would be unfortunate if a blogger was comparing languages
>> and benchmarked FFT using complex numbers from a module in the breeze.
>> Dynamic dispatch is going to devastate the benchmarks.
>> Still, it's worth pursuing this. There's a lot of things which Apple
>> supports on Apples and won't be a priority for stdlib. The quaternions you
>> mentioned are a good example. Complex numbers are another because of
>> -david https://github.com/AE9RB/SwiftGL
>> On Tue, Jan 26, 2016 at 3:32 PM, Tino Heth via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>> There have been several threads to add specific functions or types to
>>> the stdlib:
>>> - Either in the Swift Standard Library
>>> - Proposal: Add scan, takeWhile, dropWhile, and iterate to the stdlib
>>> - Higher Kinded Types (Monads, Functors, etc.)
>>> - Adding a new filter method which returns 2 arrays
>>> - Add replace(_:with:) function to the stdlib
>>> - map-like operation that returns a dictionary
>>> - Rectangles and other common structures.
>>> - Add zip2WithNilPadding function
>>> - Add types BufferedSequence, BufferedGenerator
>>> - … (guess there are some that I missed — I didn't look at last years
>>> threads at all).
>>> Afair, none of those ideas turned into real proposals, and I think that
>>> keeping stdlib small is a good goal.
>>> Nonetheless, there are plenty of data structures and algorithms that
>>> will be used in many places by many different teams, and each of them might
>>> write its own implementation. That's imho no big problem for algorithms,
>>> but for types, it will most likely lead to real annoyance.
>>> I hope that we will soon have a great package manager for Swift, but I
>>> don't think that will solve this issue completely:
>>> I wouldn't import a big third-party framework just because a tiny
>>> function like "dropWhile" could make my code more elegant...
>>> Of course, some widely accepted libs might rise and improve
>>> interoperability, but it is hard to predict how our ecosystem will evolve,
>>> and you don't have to wait for the future to see the what could happen when
>>> there is no common base:
>>> Just take a look at SCNQuaternion, GLQuaternion and CMQuaternion.
>>> Instead of asking to pollute stdlib with stuff like 3d transformations,
>>> I'd prefer a set of general purpose libraries under supervision by the
>>> Swift team:
>>> It could be a great way for "outsiders" to get into Swift development,
>>> and most likely wouldn't put to much stress and responsibility on the
>>> shoulders of each "manager".
>>> It also could take pressure from the stdlib (and this mailinglist :)
>>> Beside fields of application (graphics, images, music, algebra,
>>> statistics, pattern matching, machine learning, graph theorie... whatever
>>> raises enough interest), there could also be libraries to support concepts
>>> like functional programming.
>>> Best regards,
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>> swift-evolution mailing list
>> swift-evolution at swift.org
> Trent Nadeau
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution