Re: Future of Cocoa

[Jens Alfke via Cocoa-dev]

> On Nov 20, 2019, at 5:21 PM, Saagar Jha  wrote:
> 
> Oh, I guess I didn’t explain what I was talking about well. I’m saying that 
> the compiler would do a full method inline but put it behind a check to see 
> if it’s legal to continue executing. 

That optimization would increase code size (it can't possibly decrease it.) And 
it can't do very effective inlining, because the code to be inlined is only 
conditionally executed, so it can't really be merged into the call site. All 
you really save is the time difference between `bar_is_unswizzled` and 
`objc_msgsend`, which probably isn't very much (although you do have better 
locality of reference.)

But I am not a compiler engineer, so this is just my hobbyist opinion :)

—Jens
___

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: Future of Cocoa

[Saagar Jha via Cocoa-dev]

Oh, I guess I didn’t explain what I was talking about well. I’m saying that the 
compiler would do a full method inline but put it behind a check to see if it’s 
legal to continue executing. For example, code like this:

@interface Foo
- (void)bar;
@end

// Another method in some random class
- (void)baz {
Foo *foo = // whatever
[foo bar];
}

would end up being compiled to something like this:

- (void)baz {
Foo *foo = // whatever
if (bar_is_unswizzled()) {
// Inlined version of -[Foo bar]
} else {
// Fall back to going through objc_msgSend
}
}

where bar_is_unswizzled() is some sort of runtime check that makes sure that 
the actual target is what we had thought it’d be at compile time. I’d hope that 
a branch predictor would be able to do a pretty good job on this considering 
that the guessing “true” would work 99% of the time.

Saagar Jha

> On Nov 20, 2019, at 17:01, Jens Alfke  wrote:
> 
> 
> 
>> On Nov 20, 2019, at 2:46 PM, Saagar Jha > > wrote:
>> 
>> I am curious why this optimization went in instead of guarded speculative 
>> inlining, which would let you keep dynamism. 
> 
> If I understand it correctly, that only 'inlines' (really caches) the 
> resolved method address for the call site. That's not much of a win in Obj-C 
> where method lookup is already quite fast.
> 
> The real win comes with literally inlining the method at compile time. 
> Link-Time Optimization allows _any_ method anywhere in the program to be 
> inlined, provided the call is monomorphic. And this new feature allows 
> monomorphic method calls in Obj-C. This is a big win for small method like 
> getters/setters, and for methods with only one call site (i.e. where you 
> factor out a method for readability even though it's only used in one place.)
> 
> —Jens

___

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: Future of Cocoa

[Jens Alfke via Cocoa-dev]

> On Nov 20, 2019, at 2:46 PM, Saagar Jha  wrote:
> 
> I am curious why this optimization went in instead of guarded speculative 
> inlining, which would let you keep dynamism. 

If I understand it correctly, that only 'inlines' (really caches) the resolved 
method address for the call site. That's not much of a win in Obj-C where 
method lookup is already quite fast.

The real win comes with literally inlining the method at compile time. 
Link-Time Optimization allows _any_ method anywhere in the program to be 
inlined, provided the call is monomorphic. And this new feature allows 
monomorphic method calls in Obj-C. This is a big win for small method like 
getters/setters, and for methods with only one call site (i.e. where you factor 
out a method for readability even though it's only used in one place.)

—Jens
___

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: Future of Cocoa

[Jean-Daniel via Cocoa-dev]

Probably because the benefit is minor compare to this optimisation (which let 
the compiler completely inline the called ‘method’ if it want).

The actual method dispatch implementation is fast enough (in case of cache hit) 
to not gain much from inline caching, which introduce another layer of caching 
with its cost.
It may even slow done the software as it add some additional checks to any 
method calls.



> Le 20 nov. 2019 à 23:46, Saagar Jha via Cocoa-dev  
> a écrit :
> 
> I am curious why this optimization went in instead of guarded speculative 
> inlining, which would let you keep dynamism. Maybe that was too complicated 
> to implement or didn’t have the right performance characteristics. But I 
> guess this isn’t really the right list for discussing that…
> 
> Saagar Jha
> 
>> On Nov 20, 2019, at 14:27, Jens Alfke via Cocoa-dev 
>>  wrote:
>> 
>> 
>> 
>>> On Nov 20, 2019, at 2:16 PM, Jean-Daniel via Cocoa-dev 
>>>  wrote:
>>> 
>>> If Obj-C is dead, why is Apple still adding new language extensions (and 
>>> not minor one) ?
>>> 
>>> https://github.com/llvm/llvm-project/commit/d4e1ba3fa9dfec2613bdcc7db0b58dea490c56b1
>>>  
>>> 
>> 
>> Oh neat, this is basically non-virtual methods for Objective-C. Useful for 
>> optimization of internal methods — not just because the call is faster, but 
>> because the method body is now inlineable.
>> 
>> I remember talk of this inside Apple way back when (early 2000s) but at the 
>> time IIRC it was considered too dangerous to be worth the performance gain. 
>> These days it's probably even more of a win because of LTO.
>> 
>> —Jens
>> ___
>> 
>> 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/saagar%40saagarjha.com
>> 
>> This email sent to saa...@saagarjha.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/mailing%40xenonium.com
> 
> This email sent to mail...@xenonium.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: Future of Cocoa

[Saagar Jha via Cocoa-dev]

I am curious why this optimization went in instead of guarded speculative 
inlining, which would let you keep dynamism. Maybe that was too complicated to 
implement or didn’t have the right performance characteristics. But I guess 
this isn’t really the right list for discussing that…

Saagar Jha

> On Nov 20, 2019, at 14:27, Jens Alfke via Cocoa-dev 
>  wrote:
> 
> 
> 
>> On Nov 20, 2019, at 2:16 PM, Jean-Daniel via Cocoa-dev 
>>  wrote:
>> 
>> If Obj-C is dead, why is Apple still adding new language extensions (and not 
>> minor one) ?
>> 
>> https://github.com/llvm/llvm-project/commit/d4e1ba3fa9dfec2613bdcc7db0b58dea490c56b1
>>  
>> 
> 
> Oh neat, this is basically non-virtual methods for Objective-C. Useful for 
> optimization of internal methods — not just because the call is faster, but 
> because the method body is now inlineable.
> 
> I remember talk of this inside Apple way back when (early 2000s) but at the 
> time IIRC it was considered too dangerous to be worth the performance gain. 
> These days it's probably even more of a win because of LTO.
> 
> —Jens
> ___
> 
> 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/saagar%40saagarjha.com
> 
> This email sent to saa...@saagarjha.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: Future of Cocoa

[Jens Alfke via Cocoa-dev]

> On Nov 20, 2019, at 2:16 PM, Jean-Daniel via Cocoa-dev 
>  wrote:
> 
> If Obj-C is dead, why is Apple still adding new language extensions (and not 
> minor one) ?
> 
> https://github.com/llvm/llvm-project/commit/d4e1ba3fa9dfec2613bdcc7db0b58dea490c56b1
>  
> 

Oh neat, this is basically non-virtual methods for Objective-C. Useful for 
optimization of internal methods — not just because the call is faster, but 
because the method body is now inlineable.

I remember talk of this inside Apple way back when (early 2000s) but at the 
time IIRC it was considered too dangerous to be worth the performance gain. 
These days it's probably even more of a win because of LTO.

—Jens
___

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: Future of Cocoa

[Jean-Daniel via Cocoa-dev]

> Le 20 nov. 2019 à 01:26, Gerald Henriksen via Cocoa-dev 
>  a écrit :
> 
> On Tue, 19 Nov 2019 13:51:14 -0700, you wrote:
> 
>> When committing to 64 bit Apple said NO to Carbon but YES to Cocoa and YES 
>> to Core Foundation and YES to a lot of other stuff. The OS still has the XNU 
>> (Mach) Kernel and FreeBSD (written in C & C++), the Cocoa frameworks (base 
>> layer written in Objective-C), Swift and lots of other stuff. From my point 
>> of view I do not see Apple sweeping away Objective-C and the Cocoa 
>> frameworks any time soon. 
> 
> Just because Apple may need to keep Objective-C around for the
> frameworks doesn't mean they will continue to allow applications to be
> written in it.
> 
> All they need to do is either eliminate the option (stop shipping the
> Objective-C compiler), or do so by requiring all applications to have
> something that is only available via Swift.

If Obj-C is dead, why is Apple still adding new language extensions (and not 
minor one) ?

https://github.com/llvm/llvm-project/commit/d4e1ba3fa9dfec2613bdcc7db0b58dea490c56b1
 




___

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: Future of Cocoa

[Jens Alfke via Cocoa-dev]

> On Nov 20, 2019, at 8:28 AM, Pier Bover via Cocoa-dev 
>  wrote:
> 
> For example the vast majority of audio software
> companies are still communicating to its users to not update to Catalina.
> Huge audio companies like Native Instruments are still struggling with this.

That's misleading. Native Instruments software all runs 64-bit, as far as I'm 
aware. The issue is that a 64-bit process cannot load 32-bit plugins 
(obviously), nor communicate with a 32-bit userspace hardware driver … and many 
of NI's customers have older 3rd party VST or AU plugins or drivers that would 
stop working.

NI has previously told their customers* they can work around this by launching 
their apps in 32-bit mode, but of course that no longer works in Catalina. 
That's what the warning is about.

(There's also the fact that many major OS upgrades have changes to Core Audio 
that can cause issues with audio apps, so there always seems to be a shake-out 
period where Apple and/or the audio developer release some maintenance fixes.)

—Jens

* 
https://support.native-instruments.com/hc/en-us/articles/209592169-Managing-Applications-and-Plug-ins-on-OS-X-32-64-bit-Systems
___

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: Future of Cocoa

[Rob Petrovec via Cocoa-dev]

> On Nov 20, 2019, at 9:28 AM, Pier Bover  wrote:
> 
> > Its not Apples fault if you were not aware.  They were both highly talked 
> > about during their respective WWDC events.
> 
> The vast majority of developers do not go to the WWDC and do not have time to 
> watch the dozens (hundreds?) of hours of videos to maybe find something 
> relevant about the future of macOS dev. If that's how Apple communicates 
> their future plans then Apple has a communication problem.
32 bit being deprecated & it being killed were both announced during 
their respective WWDC keynote, if memory services, to a lot of fan fair.  If 
you only watch one WWDC video a year the keynote is the one to watch.  Its 
where most big future plans are announced.  There were also a bunch of WWDC 
sessions/videos and developer pages on how to move your products away from 32 
Bit too.  It was also covered on a bunch of Apple Developer web pages.  If you 
search around you can still find them.  It was also highly talked about on this 
and other mailing lists and forums as well as many mac news sites etc.  The 
information was there in many locations, you just had to pay attention.  Again, 
its not Apple’s fault if you were not aware.


> Companies like Adobe, Microsoft, etc, announce their plans publicly years in 
> advance. They have dedicates pages, blog posts, social media announcements 
> with dates of when these EOL changes will happen. For example Adobe announced 
> in 2017 it would kill the Flash Player by 2020.
Adobe only have you 3 years to move away from Flash Player.  Apple gave 
you 7 to move away from 32 Bit, yet you still complain?


> Personally I didn't know about 32 bits EOL until I heard about it with Mojave 
> user alerts, less than 2 years before Catalina was released. It didn't impact 
> me, but it did impact many companies that are still struggling with it. For 
> example the vast majority of audio software companies are still communicating 
> to its users to not update to Catalina. Huge audio companies like Native 
> Instruments are still struggling with this.
They had 7 years to get things in order.  I have sympathy for their 
users, but not for the company.  They either have mac developers with their 
heads in the sand, or they made a conscious business decision not to put 
resources towards moving away from 32 Bit.  In either case, again, its not 
Apple’s fault.


> Do you know for certain when Apple will stop shipping OpenGL with macOS? 
> Probably not. Most likely it will be announced less than a year before it 
> happens.
No I don’t know when OpenGL is being killed.  But Apple announced it is 
being deprecated which is your first, and very large, clue to start moving away 
from OpenGL in your products sooner rather than later.  Again, you have been 
told its going away, and historically it takes a few years for Apple to kill 
things like that.  If your products still use OpenGL by the time OpenGL is 
killed in a few years then it is totally on you, not Apple.  Just sayin’...

—Rob


___

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: Future of Cocoa

[Gary L. Wade via Cocoa-dev]

> On Nov 20, 2019, at 8:29 AM, Pier Bover via Cocoa-dev 
>  wrote:
> 
> The vast majority of developers do not go to the WWDC and do not have time
> to watch the dozens (hundreds?) of hours of videos to maybe find something
> relevant about the future of macOS dev.

In that case, scan through the online transcripts, which are searchable, and 
the keynotes of the presentations.

Really, no one has any excuse. Either use what’s available and submit feedback 
when something isn’t clear or quit developing software.
--
Gary L. Wade
http://www.garywade.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: Future of Cocoa

[Pier Bover via Cocoa-dev]

> Its not Apples fault if you were not aware.  They were both highly talked
about during their respective WWDC events.

The vast majority of developers do not go to the WWDC and do not have time
to watch the dozens (hundreds?) of hours of videos to maybe find something
relevant about the future of macOS dev. If that's how Apple communicates
their future plans then Apple has a communication problem.

Companies like Adobe, Microsoft, etc, announce their plans publicly years
in advance. They have dedicates pages, blog posts, social media
announcements with dates of when these EOL changes will happen. For example
Adobe announced in 2017 it would kill the Flash Player by 2020.

Personally I didn't know about 32 bits EOL until I heard about it with
Mojave user alerts, less than 2 years before Catalina was released. It
didn't impact me, but it did impact many companies that are still
struggling with it. For example the vast majority of audio software
companies are still communicating to its users to not update to Catalina.
Huge audio companies like Native Instruments are still struggling with this.

https://support.native-instruments.com/hc/en-us/articles/360001890378-macOS-10-15-Catalina-Compatibility-with-Native-Instruments-Products

Do you know for certain when Apple will stop shipping OpenGL with macOS?
Probably not. Most likely it will be announced less than a year before it
happens.
___

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

[Slightly OT] Cocoa developer job ad

[Mark Allan via Cocoa-dev]

Hi all,

I run a software company in the UK and we're looking to hire some full-time Mac 
software developers to join our growing team in Edinburgh, Scotland on a 
permanent basis.  We'll be advertising for junior/mid-level, and senior 
software engineer roles in all the usual places, but I've been a member of this 
list for a number of years so thought I'd reach out here too.

We're looking for people with Objective-C, who either already live locally or 
are willing to relocate to Scotland. Swift, if you have it, would be a bonus!

If that sounds like you, please get in touch with me directly and I'll send 
over some more details.

Cheers
Mark

PS. I've been on here long enough to know that such requests are supposed to go 
to the list admins first, but the email address 
cocoa-dev-admins(at)lists.apple.com just bounces back with "User unknown"!

___

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