Re: [swift-corelibs-dev] libdispatch roadmap and api addition proposal
On Mon, Dec 7, 2015, at 04:55 AM, Joakim Hassila via swift-corelibs-dev wrote:
> Secondly, we have extended the public libdispatch API internally with
> one more flavor of dispatching, let’s call it ‘dispatch_async_inline’
> - the semantics being ‘perform the processing of the work
> synchronously if we wouldn’t block the calling thread, if we would
> block, instead perform the work as a normal dispatch_async’.
>
> Would such a change be considered to be integrated, or should we keep
> our internal diffs indefinitely? Just to understand if it is worth the
> effort with a nicely packaged pull request or not...
>
> The rationale for the API is that we are quite latency sensitive and
> want to use inline processing up until the point where we can’t keep
> up with the available work, at which point we would switch to
> asynchronous processing seamlessly (we have multiple producers). This
> means that the thread calling this API can be stolen for a significant
> amount of time (emptying the queue it was assigned to), but when the
> system is under ‘light' load, we don’t need to incur the wakeup
> penalty for a completely asynchronous dispatch.
I actually have an outstanding radar asking for this exact
functionality. My proposal called it `dispatch_try_sync()`, which didn't
actually call the dispatch_async() automatically but simply returned a
boolean value telling you if it ran the code. My use-case here wasn't
actually that I wanted to run the code async, but that I needed to do
two operations on a realtime thread in any order, one of which needed to
be on a queue, so I wanted to do something like
BOOL done = dispatch_try_sync(queue, ^{ ... }); do_other_work(); if
(!done) { dispatch_sync(queue, ^{ ... }); }
My radar is still open (rdar://problem/16436943), but it got a response
as follows:
> I think the best way to "emulate" this is to use a DATA_OR source, and
> not semaphores or other things like that.
>
> Most of the issues that I've seen with trylock() tends to be uses
> looking like this:
>
> again: if (trylock()) { do { clear_marker(); do_job();
> } while(has_marker()); unlock(); } else if (!has_marker()) {
> set_marker(); goto again; }
>
> and all unlockers check for the marker to do the said job before
> unlock basically.
>
> The thing is, most of the people use that wrongly and don't loop
> properly making those coalescing checks racy, that's what dispatch
> DATA_OR sources are for.
>
> Many other uses can also be replaced with a dispatch_async()
>
> and it's very clear that the reporter can do exactly what he wants
> with a DATA_OR source. We should have a way to make sources acts as
> barriers (which I have a patch for) else we only provide half the
> required primitives.
>
> I don't see a compelling use case that can't be solved elegantly with
> data sources today.
>
> Using a DISPATCH_SOURCE_DATA_OR with a latch is a good alternative to
> what you are doing.
>
> We are continuing to work on this issue, and will follow up with
> you again.
-Kevin Ballard
___
swift-corelibs-dev mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
[swift-corelibs-dev] Can't build corelibs-libdispatch on OS X
I want to port https://github.com/apple/swift/pull/3923 to swift-corelibs-libdispatch but I can't figure out how to build swift-corelibs-libdispatch on OS X. Running `sh autogen.sh` results in src/Makefile.am:9: error: Libtool library used but 'LIBTOOL' is undefined src/Makefile.am:9: The usual way to define 'LIBTOOL' is to add 'LT_INIT' src/Makefile.am:9: to 'configure.ac' and run 'aclocal' and 'autoconf' again. src/Makefile.am:9: If 'LT_INIT' is in 'configure.ac', make sure src/Makefile.am:9: its definition is in aclocal's search path. configure.ac does include LT_INIT, but I have no idea how to make sure its definition is in aclocal's search path. I get the same problem with swift/utils/build-script --libdispatch. -Kevin Ballard ___ swift-corelibs-dev mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
Re: [swift-corelibs-dev] IndexPath performance
I agree with Stephan, NSIndexPath performance is important and we should
avoid the overhead of allocating/freeing an array for the common case.
Instead of just always wrapping NSIndexPath, maybe we should just switch
the internal representation to something like
enum Indices {
case one(Int)
case two(Int, Int)
// case three?
case many([Int])
}
Yeah it complicates the methods a bit, and we'd have to have a custom
index instead of just using Array's index, but it avoids heap allocation
for the extremely common case of a 2-element index path (it's so common,
I don't think I've *ever* seen an NSIndexPath that didn't contain
exactly 2 indices).
-Kevin Ballard
On Tue, Aug 2, 2016, at 04:24 AM, Stephan Tolksdorf via swift-corelibs-dev
wrote:
> Tony,
>
> I understand why you'd ideally want to have a real-world benchmark to
> guide performance optimisations, but if you require that for every
> performance-
> related change, you set a very high bar, and that bar will probably
> have the effect of biasing performance downwards, since if there is no
> existing benchmark, changes that worsen performance might not get
> flagged.
>
> The fact that NSIndexPath got the tagged pointer treatment probably
> indicates that its implementation has a non-negligible effect on
> performance (see also
> https://twitter.com/Catfish_Man/status/393249511075639296).
>
> The current IndexPath implementation in terms of an Int array clearly
> introduces unnecessary overhead in ObjC interop scenarios, so unless
> this implementation of IndexPath has some benefit I don't understand,
> I'd argue that it should be replaced with a straightforward wrapper
> around an NSIndexPath value.
>
> - Stephan
>
> On 2 August 2016 at 12:12, Tony Parker
> wrote:
>> Hi Stephan,
>>
>>
>>> On Aug 2, 2016, at 6:04 PM, Stephan Tolksdorf
>>> wrote:
>>>
>>> Hi Parker,
>>>
>>> I noticed the IndexPath overhead when I investigated why a Swift 3
>>> implementation of
>>> UICollectionViewLayout.layoutAttributesForElementsInRect spent more
>>> time in malloc, free and related methods, but I don't have a
>>> benchmark.
>>>
>>> Is it important that IndexPath uses native Swift refcounting? It
>>> seems to me that this type is mainly used in ObjC interop code. In
>>> native Swift code I would always try to avoid using a dynamically
>>> sized, heap allocated array as a data structure index. If
>>> NSIndexPath can't be bridged to a native Swift type without
>>> introducing additional overhead, then maybe it shouldn't be bridged
>>> at all?
>>>
>>> - Stephan
>>
>>
>>
>> I do think it is likely we could figure out some improvements here,
>> but I’d like to start with a concrete test (and something that is
>> representative of real world use cases). If it’s possible to extract
>> something out of what you’ve already done, that would be really
>> helpful. We can also file a bug on bugs.swift.org as a call for help
>> designing a better perf test suite (we need this for all of the
>> types, frankly).
>>
>> Once we know we’re measuring the right thing, there are all kinds of
>> interesting things we can do. If (when?) we have ABI stability in
>> Swift 4, we may be able to also change the ObjC Foundation.framework
>> to better cooperate with the Swift side, as we’ll be able to tie the
>> current overlay code to a specific OS instead of having to run back
>> several releases.
>>
>> Thanks,
>> - Tony
>>
>>
>>>
>>> On 2 August 2016 at 11:09, Tony Parker
>>> wrote:
Hi Stephan,
Do you have some benchmarks that you could share? That would help
us focus performance work in the right area.
I know that 2-item IndexPaths are super common with UIKit
collection view and friends, so we may just want to special case
those. Unfortunately, NSIndexPath is not abstract, so subclassing
it in the same way that we do for a few of the other bridged types
(to use native Swift refcounting) is not easy. On the other hand,
the ObjC implementation does use tagged pointers, so some
NSIndexPaths are really cheap to create.
- Tony
> On Aug 1, 2016, at 11:44 PM, Stephan Tolksdorf via swift-corelibs-
> dev wrote:
>
> Hi,
>
> IndexPath is currently implemented using an [Int] array that is
> bridged to an NSIndexPath only on demand. Since IndexPath values
> are primarily used together with Objective-C APIs, wouldn't it
> be better to implement IndexPath directly as an NSIndexPath
> wrapper, in order to avoid the overhead of temporary array
> instances?
>
> - Stephan
> ___
> swift-corelibs-dev mailing list [email protected]
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
>>>
>>
> _
> swift-corelibs-dev mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-corelibs
Re: [swift-corelibs-dev] IndexPath performance
FWIW, if you agree that this approach is reasonable, I would be willing
to write the patch for it.
-Kevin Ballard
On Tue, Aug 2, 2016, at 05:46 PM, Kevin Ballard wrote:
> I agree with Stephan, NSIndexPath performance is important and we
> should avoid the overhead of allocating/freeing an array for the
> common case. Instead of just always wrapping NSIndexPath, maybe we
> should just switch the internal representation to something like
>
> enum Indices {
> case one(Int)
> case two(Int, Int)
> // case three?
> case many([Int])
> }
>
> Yeah it complicates the methods a bit, and we'd have to have a custom
> index instead of just using Array's index, but it avoids heap
> allocation for the extremely common case of a 2-element index path
> (it's so common, I don't think I've *ever* seen an NSIndexPath that
> didn't contain exactly 2 indices).
>
> -Kevin Ballard
>
> On Tue, Aug 2, 2016, at 04:24 AM, Stephan Tolksdorf via swift-corelibs-
> dev wrote:
>> Tony,
>>
>> I understand why you'd ideally want to have a real-world benchmark to
>> guide performance optimisations, but if you require that for every
>> performance-related change, you set a very high bar, and that bar
>> will probably have the effect of biasing performance downwards, since
>> if there is no existing benchmark, changes that worsen performance
>> might not get flagged.
>>
>> The fact that NSIndexPath got the tagged pointer treatment probably
>> indicates that its implementation has a non-negligible effect on
>> performance (see also
>> https://twitter.com/Catfish_Man/status/393249511075639296).
>>
>> The current IndexPath implementation in terms of an Int array clearly
>> introduces unnecessary overhead in ObjC interop scenarios, so unless
>> this implementation of IndexPath has some benefit I don't understand,
>> I'd argue that it should be replaced with a straightforward wrapper
>> around an NSIndexPath value.
>>
>> - Stephan
>>
>> On 2 August 2016 at 12:12, Tony Parker
>> wrote:
>>> Hi Stephan,
>>>
>>>
On Aug 2, 2016, at 6:04 PM, Stephan Tolksdorf
wrote:
Hi Parker,
I noticed the IndexPath overhead when I investigated why a Swift 3
implementation of
UICollectionViewLayout.layoutAttributesForElementsInRect spent more
time in malloc, free and related methods, but I don't have a
benchmark.
Is it important that IndexPath uses native Swift refcounting? It
seems to me that this type is mainly used in ObjC interop code. In
native Swift code I would always try to avoid using a dynamically
sized, heap allocated array as a data structure index. If
NSIndexPath can't be bridged to a native Swift type without
introducing additional overhead, then maybe it shouldn't be bridged
at all?
- Stephan
>>>
>>>
>>>
>>> I do think it is likely we could figure out some improvements here,
>>> but I’d like to start with a concrete test (and something that is
>>> representative of real world use cases). If it’s possible to extract
>>> something out of what you’ve already done, that would be really
>>> helpful. We can also file a bug on bugs.swift.org as a call for help
>>> designing a better perf test suite (we need this for all of the
>>> types, frankly).
>>>
>>> Once we know we’re measuring the right thing, there are all kinds of
>>> interesting things we can do. If (when?) we have ABI stability in
>>> Swift 4, we may be able to also change the ObjC Foundation.framework
>>> to better cooperate with the Swift side, as we’ll be able to tie the
>>> current overlay code to a specific OS instead of having to run back
>>> several releases.
>>>
>>> Thanks,
>>> - Tony
>>>
>>>
On 2 August 2016 at 11:09, Tony Parker
wrote:
> Hi Stephan,
>
> Do you have some benchmarks that you could share? That would help
> us focus performance work in the right area.
>
> I know that 2-item IndexPaths are super common with UIKit
> collection view and friends, so we may just want to special case
> those. Unfortunately, NSIndexPath is not abstract, so subclassing
> it in the same way that we do for a few of the other bridged
> types (to use native Swift refcounting) is not easy. On the other
> hand, the ObjC implementation does use tagged pointers, so some
> NSIndexPaths are really cheap to create.
>
> - Tony
>
> > On Aug 1, 2016, at 11:44 PM, Stephan Tolksdorf via swift-corelibs-
> > dev wrote:
> >
> > Hi,
> >
> > IndexPath is currently implemented using an [Int] array that is
> > bridged to an NSIndexPath only on demand. Since IndexPath
> > values are primarily used together with Objective-C APIs,
> > wouldn't it be better to implement IndexPath directly as an
> > NSIndexPath wrapper, in order to avoid the overhead of
> > temporary array instances?
> >
> > - Stephan
> > ___
> > s
