[swift-evolution] Pitch: (Almost) std libs

[David Turnbull]

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:
https://github.com/AE9RB/SwiftGL
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.

-david

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
>> Accelerate.
>>
>> -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,
>>> Tino
>>>
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>
>
> --
> Trent Nadeau
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160126/93264d97/attachment.html>