Re: Cocoa-dev Digest, Vol 13, Issue 415

[Graham Cox]

> On 30 Sep 2016, at 3:48 AM, Gabriel Zachmann  wrote:
> 
> I was just a little bit hesitant to use the regular ScreenSaverDefaults for 
> those really small pieces of data that change every time,
> because I already use the ScreenSaverDefaults to store quite a bit of other 
> data (that changes only rarely) , in total 15 MB.
> 
> That means the OS has to write all of that data back to disk just because I 
> have changed an integer,
> doesn't it?


Don’t prematurely optimize.

Try it and see. How defaults are implemented is hidden - it may be a disk write 
or it may not, that’s a detail you don’t need to consider. If it turns out it’s 
really slow, and that is a problem, then worry about it. I suspect you won’t 
have to.

—Graham



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: iOS app communicating with macOS app

[Georg Seifert]

Maybe this helps: https://github.com/rsms/peertalk 


Best
Georg Seifert

> On 28 Sep 2016, at 14:57, Eric E. Dolecki  wrote:
> 
> I'd like to make an iOS application communicate with a macOS application.
> No App Store involvement - just to prototype something local. What would be
> the best approach/easiest solution? A GameKit type thing or something else
> like BLE or something maybe even easier? Would only need to send small
> strings.
> 
> Thanks,
> Eric
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/georg.seifert%40gmx.de
> 
> This email sent to georg.seif...@gmx.de

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Best way to make a little piece of data persistent?

[Gabriel Zachmann]

I need to make a few small pieces of data (an integer, a string, ...)
persistent across different invocations of my screen saver.

That is, when the screen saver is about to quit, I need to save it,
when it gets invoked the next time, I need to load it again.

What is the recommended (and easiest?) way to do that?

All suggestions will be highly appreciated.
Best regards, 
Gabriel.



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Cocoa-dev Digest, Vol 13, Issue 415

[Gabriel Zachmann]

>> 
>> I need to make a few small pieces of data (an integer, a string, ...)
>> persistent across different invocations of my screen saver.
>> 
>> That is, when the screen saver is about to quit, I need to save it,
>> when it gets invoked the next time, I need to load it again.
>> 
>> What is the recommended (and easiest?) way to do that?
> 
> NSUserDefaults

Thanks, I believe I have to use ScreenSaverDefaults, then? because
the documentation for ScreenSaverDefaults says:
"Because screen savers are packaged as bundles and loaded by several different 
applications, it is not possible to use NSUserDefaults to store user 
preferences for them."

I was just a little bit hesitant to use the regular ScreenSaverDefaults for 
those really small pieces of data that change every time,
because I already use the ScreenSaverDefaults to store quite a bit of other 
data (that changes only rarely) , in total 15 MB.

That means the OS has to write all of that data back to disk just because I 
have changed an integer,
doesn't it?

Best regards, 
Gabriel.



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Have tool tips displayed longer?

[Gabriel Zachmann]

Is there a way to adjust the duration how long the tool tips of my GUI are 
displayed during runtime?
(I'd like macOS to display them longer than the default.)

Best regards, 
Gabriel.






___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: URL.setResourceValues() in Swift 3

[Quincey Morris]

On Sep 29, 2016, at 13:29 , Rick Mann  wrote:
> 
> So, it turns out, destURL was a let, not a var. That made the difference. 
> Sure seems like a bad diagnostic.

Yes, with that piece of extra information, I can see the same behavior in Xcode 
8.1 that you originally described (with AnyObject instead of Any, as you said).

> However, there's also a problem in that the documentation in Xcode 8 is:
> 
>   func setResourceValues(_ keyedValues: [URLResourceKey : Any]) throws

I think what’s happening is that three different things are getting confused by 
the compiler (because destURL was not mutable, so the “natural” 
setResourceValues for type URL could not be inferred):

1. The setResourceValues method of URL (URLResourceValues).

2. The setResourceValues method of NSURL, translated across the Swift 3 API 
conversion applied to the Obj-C-based SDK ([URLResourceKey:Any]).

3. The setResourceValues method signature of NSURL, derived directly from the 
SDK header file without Swift 3 translation ([URLResourceKey:AnyObject]).

Obviously, #3 shouldn’t be happening. It doesn’t seem like #2 should be 
happening either, given that Swift 3 isn’t supposed to bridge automatically any 
more. And, yes, the error message is a secondary error that obscures the real 
problem.

So this may be 3 bugs rather than just 1. 3 gold stars for you.

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: URL.setResourceValues() in Swift 3

[Rick Mann]

> On Sep 29, 2016, at 10:54 , Quincey Morris 
>  wrote:
> 
> On Sep 29, 2016, at 04:18 , Rick Mann  wrote:
>> 
>> var vals = URLResourceValues()
>> vals.isExcludedFromBackup = true
>> try destURL.setResourceValues(vals)
>> 
>> But I get "Cannot convert value of type 'URLResourceValues' to expected 
>> argument type '[URLResourceKey : AnyObject]'" on the "vals" argument. The 
>> problem is that the docs say it's supposed to take [URLResourceKey : Any].
>> 
>> The Swift interface file generated by Xcode looks like this:
>> 
>>public mutating func setResourceValues(_ values: URLResourceValues) throws
>> 
>> But that's clearly not what the compiler sees.
> 
> What is the type of ‘destURL’? URL or NSURL? It sounds like it’s NSURL.

Nope, it's URL.

> The function signature in class NSURL is:
> 
>>  func setResourceValues([URLResourceKey : Any])
> 
> whereas the function signature in class URL is:
> 
>>  func setResourceValues(_ values: URLResourceValues)
> 
> So, you either need to change destURL to be a URL, or use the NSURL API that 
> takes a dictionary. Note that URL is not just a cosmetic renaming of NSURL in 
> Swift 3, but a whole new type that wraps a NSURL object. Both types are 
> accessible, though you’re going to have the best Swift 3 experience if you 
> switch to URL — and its altered API and semantics.
> 
> Regarding Any vs. AnyObject as the dictionary value, the error message I get 
> (in Xcode 8.1 beta, with the above code) is:
> 
>>  Cannot convert value of type 'URLResourceValues' to expected argument 
>> type '[URLResourceKey : Any]’
> 
> So, you’re either not compiling against the 10.12 SDK (which I think should 
> be impossible), or you’re compiling as Swift 2.3, or Xcode at least thinks 
> you are.

So, it turns out, destURL was a let, not a var. That made the difference. Sure 
seems like a bad diagnostic.

However, there's also a problem in that the documentation in Xcode 8 is:

func setResourceValues(_ keyedValues: [URLResourceKey : Any]) throws

But the Xcode generated interface shows it as:

public mutating func setResourceValues(_ values: URLResourceValues) 
throws

And incidentally, it seems Xcode's code completion still isn't reliable, in 
that I can command-click on URL, but not on setResourceValues (I just get a ? 
appearing).

I'll write a bug.

-- 
Rick Mann
rm...@latencyzero.com



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Normalising file names on macOS

[Clark Cox]

> On Sep 22, 2016, at 08:30, Ken Thomases  wrote:
> 
> On Sep 22, 2016, at 6:04 AM, John Brownie  wrote:
>> 
>> I find that I am in need of dealing with versions of strings that may be 
>> turned into file names, and thus I need to be comparing normalised forms.

If you need to compare unicode strings, you don't need to worry about the 
normalization form (if any) of either string as long as you either normalize 
them yourself or your a method of comparing them that does canonical comparison 
(e.g. -compare:).

>> However, according to 
>> https://developer.apple.com/library/content/qa/qa1173/_index.html, "For 
>> example, HFS Plus (Mac OS Extended) uses a variant of Normal Form D in which 
>> U+2000 through U+2FFF, U+F900 through U+FAFF, and U+2F800 through U+2FAFF 
>> are not decomposed (this avoids problems with round trip conversions from 
>> old Mac text encodings)."
>> 
>> Is there a way to get at this variant? [NSString 
>> decomposedStringWithCanonicalMapping] returns "A string made by normalizing 
>> the string’s contents using the Unicode Normalization Form D." That seems 
>> not to give what I need, but I haven't seen a better option. Is there such a 
>> method?
> 
> Without undermining Alastair's recommendations, you can achieve what you want 
> by round-tripping the string through -[NSString fileSystemRepresentation] and 
> -[NSFileManager stringWithFileSystemRepresentation:length:].  That handles 
> the normalization, but it doesn't do anything about characters that aren't 
> legal in file names on a given file system.

That is not entirely correct, whether or not those methods do normalization 
varies from one OS version to another, and it is not actually part of the API 
contract.



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Multipeer between macOS Sierra and iOS 10

[Eric E. Dolecki]

I emailed the list yesterday about getting communication going between an
iOS application and a macOS one. I coded it up this morning and it works
quite well. However the consoles are filled with Errors eventhough things
are connected and send data back and forth.

Things like:
[ViceroyTrace] [ICE][ERROR] ICEStopConnectivityCheck() found no ICE check
with call id (1506554834)
[ViceroyTrace] [ICE][ERROR] Send BINDING_REQUEST failed(C01A0041).
[ViceroyTrace] [ICE][ERROR] Send BINDING_REQUEST failed(C01A0041).
...
[GCKSession] Not in connected state, so giving up for participant
[59CC33D2] on channel [0].
[GCKSession] Not in connected state, so giving up for participant
[59CC33D2] on channel [2].
[GCKSession] Not in connected state, so giving up for participant
[59CC33D2] on channel [2].
...
[MCBrowserViewController] MCBrowserViewController shouldn't be receiving
this callback. *(connected)*

Is this some kind of bug that needs corrected behind the scenes or are
these errors genuine and require me to worry about?

Eric
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: URL.setResourceValues() in Swift 3

[Quincey Morris]

On Sep 29, 2016, at 04:18 , Rick Mann  wrote:
> 
> var vals = URLResourceValues()
> vals.isExcludedFromBackup = true
> try destURL.setResourceValues(vals)
> 
> But I get "Cannot convert value of type 'URLResourceValues' to expected 
> argument type '[URLResourceKey : AnyObject]'" on the "vals" argument. The 
> problem is that the docs say it's supposed to take [URLResourceKey : Any].
> 
> The Swift interface file generated by Xcode looks like this:
> 
>public mutating func setResourceValues(_ values: URLResourceValues) throws
> 
> But that's clearly not what the compiler sees.

What is the type of ‘destURL’? URL or NSURL? It sounds like it’s NSURL.

The function signature in class NSURL is:

>   func setResourceValues([URLResourceKey : Any])


whereas the function signature in class URL is:

>   func setResourceValues(_ values: URLResourceValues)


So, you either need to change destURL to be a URL, or use the NSURL API that 
takes a dictionary. Note that URL is not just a cosmetic renaming of NSURL in 
Swift 3, but a whole new type that wraps a NSURL object. Both types are 
accessible, though you’re going to have the best Swift 3 experience if you 
switch to URL — and its altered API and semantics.

Regarding Any vs. AnyObject as the dictionary value, the error message I get 
(in Xcode 8.1 beta, with the above code) is:

>   Cannot convert value of type 'URLResourceValues' to expected argument 
> type '[URLResourceKey : Any]’

So, you’re either not compiling against the 10.12 SDK (which I think should be 
impossible), or you’re compiling as Swift 2.3, or Xcode at least thinks you are.

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Implementing own text prediction on UITextField

[David Duncan]

There is not.

> On Sep 29, 2016, at 4:34 AM, Devarshi Kulshreshtha 
>  wrote:
> 
> Currently when we type on a text field it shows text prediction over
> keyboard on a bar, is there any way to populate the same with say a
> dictionary, or a plist, etc. Basically populating it using own data source
> rather than system data source.
> 
> Any ideas guys?
> 
> Thanks in advance.
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/david.duncan%40apple.com
> 
> This email sent to david.dun...@apple.com

--
David Duncan


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

NSSecureTextField and Umlaute and the likes

[Michael Starke]

I'm developing a password manager that uses an NSSecureTextField for the user 
to type a password.
The Problem is, that on some keyboard layout keys like ñ have to be typed using 
multiple keys or can be inserted via a hold on the key and then selecting the 
special one via the popup.
This works on all inputs except the NSSecureTextField. It's neither possible to 
type the key with a key-combination nor is the long press not working. The 
later seems obvious but the first is somewhat strange.

I tried to search for a common subclass that tries to fix this problem but 
haven't come up with anything and trying to mess with the NSSecureTextView did 
not work in the past for me trying to fix another problem.

Has anyone encountered and possibly solved the issue?

Thanks in advance,
Michael 

___m i c h a e l   s t a r k e 
   geschäftsführer
   HicknHack Software GmbH
   www.hicknhack-software.com
   
___k o n t a k t
   +49 (170) 3686136
   cont...@hicknhack.com
   
___H i c k n H a c k   S o f t w a r e   G m b H
   geschäftsführer - maik lathan | andreas reischuck | michael starke
   bayreuther straße 32
   01187 dresden
   amtsgericht dresden HRB 30351
   sitz - dresden


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Implementing own text prediction on UITextField

[Devarshi Kulshreshtha]

Currently when we type on a text field it shows text prediction over
keyboard on a bar, is there any way to populate the same with say a
dictionary, or a plist, etc. Basically populating it using own data source
rather than system data source.

Any ideas guys?

Thanks in advance.
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

URL.setResourceValues() in Swift 3

[Rick Mann]

I don't know if Xcode 8 just has more bugs showing headers, or what. But I'm 
trying to make this call, as documented in the docs:


let _ = fm.createIntermediateDirectories(destURL)
try destURL.setResourceValues([. isExcludedFromBackup : true])

But I get "Value of type 'Bool' does not conform to expected dictionary value 
type 'AnyObject'" on the true. So I tried:

var vals = URLResourceValues()
vals.isExcludedFromBackup = true
try destURL.setResourceValues(vals)

But I get "Cannot convert value of type 'URLResourceValues' to expected 
argument type '[URLResourceKey : AnyObject]'" on the "vals" argument. The 
problem is that the docs say it's supposed to take [URLResourceKey : Any].

The Swift interface file generated by Xcode looks like this:

public mutating func setResourceValues(_ values: URLResourceValues) throws

But that's clearly not what the compiler sees.

Damn these bugs really suck.

Anyone know how to make this call work?

Thanks.


-- 
Rick Mann
rm...@latencyzero.com



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Mystery Threads

[Roland King]

> On 29 Sep 2016, at 16:59, Gerriet M. Denkmann  wrote:
> 
> 
>> On 29 Sep 2016, at 15:34, Quincey Morris 
>>  wrote:
>> 
>> On Sep 29, 2016, at 01:05 , Gerriet M. Denkmann  wrote:
>>> 
>>> Well, nothing. Just let’s call it nbrOfBlocksToBeUsedByDispatchApply, or 
>>> whatever. But ultimately any of these things has to run on a CPU, of which 
>>> there are no more than 8.
>> 
>> Well, here’s my narrative. It may be fiction or non-fiction.
>> 
>> You said you tried “nbrOf…” as a few ten-thousands, vs. 8. Let’s be concrete 
>> and call this (a) 40,000 vs. (b) 8. So, for each set of 40,000 iterations of 
>> your block, you’re doing 1 dispatch_apply in case #a, and 5,000 
>> dispatch_apply calls in case #b. So, you’ve established that 4,999 
>> dispatch_apply calls — and related per-dispatch_appy overhead — take a long 
>> time.
> 
> Well, I count this as (bigArea = 4 GB):
> (a) one call of dispatch_appy which schedules 40 000 times a block to GCD 
> which handles 0.1 MB
> (b) one call of dispatch_appy which schedules 8 times a block to GCD which 
> handles 500 MB
> 
> Could be that these blocks sometimes collide (maybe when they are operating 
> on adjacent areas), which slows them down. Such a collision is rather 
> unlikely if only 8 of 40 000 are running.
> 
> 
>> Of course, I’m relying on the fact that you’re doing the same number of 
>> *total* iterations of your inner loop in case #a and case #b. This is not 
>> quite the whole story, because there are loop setup overheads per block. 
>> However, the loop setup that you’ve shown is very simple — a couple of Int 
>> operations — so the additional 4,999 loop setup executions are likely 
>> dwarfed by 4,999 dispatch_apply executions.
> 
> The actual story is: one outer loop (same in all cases) which sets up some 
> parameters, then another loop which covers the area which is assigned to this 
> block.
> In case (a) this area is small: 0.1 MB, whereas in case (b) it is large: 500 
> MB. Which seems to be in favour of case (b).
> 
> 

Why guess - this is exactly what Instruments is designed to tell you. It’s even 
dispatch-aware so it can show you results broken down by dispatch queue and 
worker thread inside the dispatch queue. Run the two under instruments and find 
out where all the time is spent. 


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Mystery Threads

[Gerriet M. Denkmann]

> On 29 Sep 2016, at 15:34, Quincey Morris 
>  wrote:
> 
> On Sep 29, 2016, at 01:05 , Gerriet M. Denkmann  wrote:
>> 
>> Well, nothing. Just let’s call it nbrOfBlocksToBeUsedByDispatchApply, or 
>> whatever. But ultimately any of these things has to run on a CPU, of which 
>> there are no more than 8.
> 
> Well, here’s my narrative. It may be fiction or non-fiction.
> 
> You said you tried “nbrOf…” as a few ten-thousands, vs. 8. Let’s be concrete 
> and call this (a) 40,000 vs. (b) 8. So, for each set of 40,000 iterations of 
> your block, you’re doing 1 dispatch_apply in case #a, and 5,000 
> dispatch_apply calls in case #b. So, you’ve established that 4,999 
> dispatch_apply calls — and related per-dispatch_appy overhead — take a long 
> time.

Well, I count this as (bigArea = 4 GB):
(a) one call of dispatch_appy which schedules 40 000 times a block to GCD which 
handles 0.1 MB
(b) one call of dispatch_appy which schedules 8 times a block to GCD which 
handles 500 MB

Could be that these blocks sometimes collide (maybe when they are operating on 
adjacent areas), which slows them down. Such a collision is rather unlikely if 
only 8 of 40 000 are running.


> Of course, I’m relying on the fact that you’re doing the same number of 
> *total* iterations of your inner loop in case #a and case #b. This is not 
> quite the whole story, because there are loop setup overheads per block. 
> However, the loop setup that you’ve shown is very simple — a couple of Int 
> operations — so the additional 4,999 loop setup executions are likely dwarfed 
> by 4,999 dispatch_apply executions.

The actual story is: one outer loop (same in all cases) which sets up some 
parameters, then another loop which covers the area which is assigned to this 
block.
In case (a) this area is small: 0.1 MB, whereas in case (b) it is large: 500 
MB. Which seems to be in favour of case (b).


Kind regards,

Gerriet.


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Mystery Threads

[Daniel Vollmer]

> On 29 Sep 2016, at 10:05, Gerriet M. Denkmann  wrote:
> 
> 
>> On 29 Sep 2016, at 14:38, Quincey Morris 
>>  wrote:
>> 
>> On Sep 29, 2016, at 00:15 , Gerriet M. Denkmann  wrote:
>>> 
>>> dispatch_apply( nbrOfThreads, queue, ^void(size_t idx)
>>> 
>>> As my computer has just 8 CPUs, I thought that using nbrOfThreads > 8 would 
>>> be silly: adding overhead without gaining anything.
>>> 
>>> Turns out this is quite wrong. One function (called threadHappyFunction) 
>>> works more than 10 times faster using nbrOfThreads = a few ten-thousand (as 
>>> compared to nbrOfThreads = 8).
>>> 
>>> This is nice, but I would like to know why can this happen.
>> 
>> What makes you think “nbrOfThreads” represents a number of threads?
> 
> Well, nothing. Just let’s call it nbrOfBlocksToBeUsedByDispatchApply, or 
> whatever. But ultimately any of these things has to run on a CPU, of which 
> there are no more than 8.

There are mored shared resources than just execution units in your system (e.g. 
memory bandwidth, or for non-linear accesses latency). Maybe one of your blocks 
is bandwidth bound, while the other is compute bound? Your second function 
might be memory bound (with lots of read-modify-write traffic). There are many 
other factors (and the dispatch_apply man-page tells you that number of 
invocations is very dependant on your block), such as caches or 
hyper-threading. The performance counters in Instruments may be able to guide 
you.

Daniel.


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Mystery Threads

[Quincey Morris]

On Sep 29, 2016, at 01:05 , Gerriet M. Denkmann  wrote:
> 
> Well, nothing. Just let’s call it nbrOfBlocksToBeUsedByDispatchApply, or 
> whatever. But ultimately any of these things has to run on a CPU, of which 
> there are no more than 8.

Well, here’s my narrative. It may be fiction or non-fiction.

You said you tried “nbrOf…” as a few ten-thousands, vs. 8. Let’s be concrete 
and call this (a) 40,000 vs. (b) 8. So, for each set of 40,000 iterations of 
your block, you’re doing 1 dispatch_apply in case #a, and 5,000 dispatch_apply 
calls in case #b. So, you’ve established that 4,999 dispatch_apply calls — and 
related per-dispatch_appy overhead — take a long time.

Of course, I’m relying on the fact that you’re doing the same number of *total* 
iterations of your inner loop in case #a and case #b. This is not quite the 
whole story, because there are loop setup overheads per block. However, the 
loop setup that you’ve shown is very simple — a couple of Int operations — so 
the additional 4,999 loop setup executions are likely dwarfed by 4,999 
dispatch_apply executions.

>> Isn’t this what Instruments is for?
> 
> Might be. I already looked at Time Profiler, but failed to notice anything 
> (maybe was looking at the wrong things) and System Trace, but did not 
> understand what to observe or what the Instrument was telling me.

Unfortunately, I agree, Instruments is inscrutable initially, and has a nasty 
learning curve. You kind of have to persist, poking around till things start to 
make a little sense. Since you want to know where time is being spent, Time 
Profiler sounds like the right place to start.

One possible approach is to profile case #a and case #b, and compare the 
Instruments output. Since you know what the actual performance difference is 
(in general terms), you should be able to see that reflected in what 
Instruments tells you. That should give you some reference points.

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Mystery Threads

[Gerriet M. Denkmann]

> On 29 Sep 2016, at 14:38, Quincey Morris 
>  wrote:
> 
> On Sep 29, 2016, at 00:15 , Gerriet M. Denkmann  wrote:
>> 
>>  dispatch_apply( nbrOfThreads, queue, ^void(size_t idx)
>> 
>> As my computer has just 8 CPUs, I thought that using nbrOfThreads > 8 would 
>> be silly: adding overhead without gaining anything.
>> 
>> Turns out this is quite wrong. One function (called threadHappyFunction) 
>> works more than 10 times faster using nbrOfThreads = a few ten-thousand (as 
>> compared to nbrOfThreads = 8).
>> 
>> This is nice, but I would like to know why can this happen.
> 
> What makes you think “nbrOfThreads” represents a number of threads?

Well, nothing. Just let’s call it nbrOfBlocksToBeUsedByDispatchApply, or 
whatever. But ultimately any of these things has to run on a CPU, of which 
there are no more than 8.

> 
>> Why are the threads seemingly blocking each other?
>> What is going on here?
>> How can I investigate this?
> 
> Isn’t this what Instruments is for?

Might be. I already looked at Time Profiler, but failed to notice anything 
(maybe was looking at the wrong things) and System Trace, but did not 
understand what to observe or what the Instrument was telling me.
Maybe some other Instrument would help?
What should I look for?


Kind regards,

Gerriet.


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Mystery Threads

[Quincey Morris]

On Sep 29, 2016, at 00:15 , Gerriet M. Denkmann  wrote:
> 
>   dispatch_apply( nbrOfThreads, queue, ^void(size_t idx)
> 
> As my computer has just 8 CPUs, I thought that using nbrOfThreads > 8 would 
> be silly: adding overhead without gaining anything.
> 
> Turns out this is quite wrong. One function (called threadHappyFunction) 
> works more than 10 times faster using nbrOfThreads = a few ten-thousand (as 
> compared to nbrOfThreads = 8).
> 
> This is nice, but I would like to know why can this happen.

What makes you think “nbrOfThreads” represents a number of threads?

> Why are the threads seemingly blocking each other?
> What is going on here?
> How can I investigate this?

Isn’t this what Instruments is for?

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Mystery Threads

[Aandi Inston]

My thoughts are general, not specific to Mac OS... The idea that the best
performance comes from threads = #CPUs is attractive, but will work only if
the threads do not sleep and do not interfere with each other. A classic
example is dividing up a complex calculation that runs without touching the
disk, reading large arrays, or sharing variables.

To construct a case where more than #CPUs might help, consider a thread
which sets up and reads from a network connection, then does something
trivial and repeats. If you have threads=#CPUs, each thread will start and
issue a network read. Then all the threads will wait for a reply and the
CPU is idle. More threads might help. But they might overwhelm the network,
so it might not be a good plan to have thousands. Exactly the same applies
if the thead reads or writes the disk. The thread might read the disk
deliberately, or it might get a page fault. More threads might help, but
the bottleneck is likely to be the disk, so the number of threads is almost
irrelevant.

Where threads run simultaneously on different CPUs, you want for best
performance to allow each CPU to work with data in its cache. Where one
thread writes a memory location that is read by another thread, the CPUs
are likely to have to flush their cache, and the multi-CPU performance
becomes that of an uncached CPU, which can be terrible. The hardware issues
here are complex and I haven't kept up with them; perhaps cache sharing has
improved.

On 29 September 2016 at 08:15, Gerriet M. Denkmann  wrote:

> I have a big array (like a few GB) which is operated upon by some
> functions.
> As these functions act purely local, an obvious idea is:
>
> - (void)someFunction
> {
> nbrOfThreads = ...
> sizeOfBigArray = ...  a few GB
> stride = sizeOfBigArray / nbrOfThreads
>
> dispatch_apply( nbrOfThreads, queue, ^void(size_t idx)
> {
> start = idx * stride
> end = start + stride
>
> index = start
> while ( index < end )
> {
> mask = ...
> bigArray[index] |= mask
> index += … something positive…
> }
> }
> )
> }
>
> As my computer has just 8 CPUs, I thought that using nbrOfThreads > 8
> would be silly: adding overhead without gaining anything.
>
> Turns out this is quite wrong. One function (called threadHappyFunction)
> works more than 10 times faster using nbrOfThreads = a few ten-thousand (as
> compared to nbrOfThreads = 8).
>
> This is nice, but I would like to know why can this happen.
>
> Another function does not like threads at all:
>
> - (void)threadShyFunction
> {
> nbrOfThreads = ...
> uint64_t *bigArrayAsLongs = (uint64_t *)bigArray
> sizeOfBigArrayInLongs = ...
> stride = sizeOfBigArrayInLongs / nbrOfThreads
>
> uint64_t *template = ...
> sizeOfTemplate = not more than a few dozen longs
>
> dispatch_apply( nbrOfThreads, queue, ^void(size_t idx)
> {
> start = idx * stride
> end = start + stride
>
> offset = start
>
> while ( offset + sizeOfTemplate < end )
> {
> for ( i = 0 ..< sizeOfTemplate )
> bigArrayAsLongs[offset + i] |= template[i]
> offset += sizeOfTemplate
> }
> }
> )
> }
>
> This works, but for nbrOfThreads > 1 it gets slower instead of faster. Up
> to hundred times slower for moderately big nbrOfThreads.
> This really bothers me.
> Why are the threads seemingly blocking each other?
> What is going on here?
> How can I investigate this?
>
> Gerriet.
>
> P.S. macOS 12, Xcode 8, ObjC or Swift.
>
>
> ___
>
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/aandi%40quite.com
>
> This email sent to aa...@quite.com
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Mystery Threads

[Gerriet M. Denkmann]

I have a big array (like a few GB) which is operated upon by some functions.
As these functions act purely local, an obvious idea is:

- (void)someFunction
{
nbrOfThreads = ...
sizeOfBigArray = ...  a few GB
stride = sizeOfBigArray / nbrOfThreads

dispatch_apply( nbrOfThreads, queue, ^void(size_t idx)
{
start = idx * stride
end = start + stride

index = start   
while ( index < end )
{
mask = ...
bigArray[index] |= mask
index += … something positive…
}
}
)
}

As my computer has just 8 CPUs, I thought that using nbrOfThreads > 8 would be 
silly: adding overhead without gaining anything.

Turns out this is quite wrong. One function (called threadHappyFunction) works 
more than 10 times faster using nbrOfThreads = a few ten-thousand (as compared 
to nbrOfThreads = 8).

This is nice, but I would like to know why can this happen.

Another function does not like threads at all:

- (void)threadShyFunction
{
nbrOfThreads = ...
uint64_t *bigArrayAsLongs = (uint64_t *)bigArray
sizeOfBigArrayInLongs = ... 
stride = sizeOfBigArrayInLongs / nbrOfThreads

uint64_t *template = ...
sizeOfTemplate = not more than a few dozen longs

dispatch_apply( nbrOfThreads, queue, ^void(size_t idx)
{
start = idx * stride
end = start + stride

offset = start

while ( offset + sizeOfTemplate < end )
{
for ( i = 0 ..< sizeOfTemplate ) 
bigArrayAsLongs[offset + i] |= template[i]
offset += sizeOfTemplate
}
}
)
}

This works, but for nbrOfThreads > 1 it gets slower instead of faster. Up to 
hundred times slower for moderately big nbrOfThreads.
This really bothers me. 
Why are the threads seemingly blocking each other?
What is going on here?
How can I investigate this?

Gerriet.

P.S. macOS 12, Xcode 8, ObjC or Swift.


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com