1. cocoa@apple-dev.groups.io
  2. Messages
   Date   
Re: SwiftUI AttributedString on Watch

Alex Zavatone
 

Would you use a sizeToFit or sizeThatFits method call to do that for you even after you’ve set the attributed text?

I have some old Objective-C libraries that I wrote for CVS to set iOS app text to their standard fonts.

Here’s a chunk of it.  You can see how I apply the font size to the dictionary.  Cheers!

   // Set base font & size.
    CGFloat fontSize = 20.0;
    UIFont *fnt = [UIFont fontWithName:@"Helvetica" size:fontSize]; // never initialize a font with a size of 0.0, or it will always be Helvetica

    

    // Define base string.
    NSString *myString;
    //myString = @"beauty club®"; // with R
    myString = @"beauty club™"; // with TM

    

    // Define base color and font definitions.

    

    fontSize = 24;
    UIColor *myBlue = [UIColor colorWithRed:.02 green:.48 blue:.66 alpha:1.0]; // Unused.  Kept as an example.
    UIColor *myPink = [UIColor colorWithRed:.93 green:.36 blue:.62 alpha:1.0];
    UIFont *thickFont = [UIFont fontWithName:@"HelveticaNeue-Bold" size:fontSize];
    UIFont *thinFont = [UIFont fontWithName:@"HelveticaNeue-Light" size:fontSize];
    thinFont = [UIFont fontWithName:@"HelveticaNeue-Medium" size:fontSize];

    

    // Define attributes dictionary for bold text.
    NSDictionary *boldAttributes = [NSDictionary dictionaryWithObjectsAndKeys:
                                    thickFont, NSFontAttributeName,
                                    myPink, NSForegroundColorAttributeName,
                                    nil];

    

    // Find range of text to make bold.
    NSString *textToBeBoldAndPink = @"beauty";
    NSRange boldAndPinkRange = [myString rangeOfString:textToBeBoldAndPink];

    

    // Define attributes dictionary for thin text.
    NSDictionary *thinAttributes = [NSDictionary dictionaryWithObjectsAndKeys:
                                    thinFont, NSFontAttributeName,
                                    myPink, NSForegroundColorAttributeName,
                                    nil];

    

    // Find range of text to make thin.
    NSString *textToBeThin;
    //        textToBeThin= @"club®"; // with R
    textToBeThin= @"club™"; // with TM
    NSRange thinTextRange = [myString rangeOfString:textToBeThin];

    

    

    // Make the basic attributed string
    NSMutableAttributedString *attributedString = [[NSMutableAttributedString alloc] initWithString:myString
                                                                                         attributes:@{NSFontAttributeName: [fnt fontWithSize:fontSize]}];

    

    // Apply bold and thin formatting to strings using appropriate ranges.
    [attributedString setAttributes:boldAttributes range:boldAndPinkRange];
    [attributedString setAttributes:thinAttributes range:thinTextRange];

    

    // AZ - find position of desired character to superscript in string
    NSString *charToFind;
    //charToFind = @"®"; // In case we are using R instead.  Just an example.
    charToFind = @"™"; // In case we are using TM instead.  Just an example.

    

    NSRange positionOfSuperscriptCharacter = [myString rangeOfString:charToFind];

    

    // Setting the point sizes using exact numbers
    //  NSInteger superscriptCharSize = 12;
    //  CGFloat pointsToRaiseBaseLineOfSupercriptChar = 8.0;
    //  UIColor *colorOfSuperText = myPink;
    //  NSNumber *characterBaselineOffsetUp = [NSNumber numberWithFloat:pointsToRaiseBaseLineOfSupercriptChar];

    

    // Set point size of superscript text relative to display font size as a percentage of original.
    CGFloat superscriptCharacterPercentOfFullsizeText = 0.60f; // 12 pt if original is 20 point
    NSInteger superscriptCharSize = fontSize * superscriptCharacterPercentOfFullsizeText ;

    

    // Set points to raise superscript text relative to font size as a percentage of original.

    

    CGFloat superscriptCharacterPercentOfFullsizeTextToRaiseChar = 0.40f; // 8 points if original is 20 point
    CGFloat pointsToRaiseBaseLineOfSupercriptChar = fontSize * superscriptCharacterPercentOfFullsizeTextToRaiseChar ;

    

    NSNumber *characterBaselineOffsetUp = [NSNumber numberWithFloat:pointsToRaiseBaseLineOfSupercriptChar];

    

    // Set color for text.
    UIColor *colorOfSuperText = myPink;

    

    // Set attributes to be applied to string.
    NSDictionary *superTextAttributes = [NSDictionary dictionaryWithObjectsAndKeys:
                                         [fnt fontWithSize:superscriptCharSize], NSFontAttributeName,
                                         colorOfSuperText, NSForegroundColorAttributeName,
                                         characterBaselineOffsetUp, NSBaselineOffsetAttributeName,
                                         nil];

    

    // Apply the formatting for the superscript to the range of text for the string.
    [attributedString setAttributes:superTextAttributes range:positionOfSuperscriptCharacter];

    

    return attributedString;


On Nov 7, 2022, at 6:06 AM, Gerriet M. Denkmann <gerriet@...> wrote:

I have a Watch-App using SwiftUI.

let fontSize = 40.0
struct WatchContentView: View
{
@State var timeAttributedStr = AttributedString("--")
let timer = Timer.publish(every: 1, tolerance: 0.1, on: .main, in: .common).autoconnect()

var body: some View
{
VStack
{
Text(timeAttributedStr)
}
.onReceive(timer)
{ currentTime  in

timeAttributedStr = … make from currentTime using fontSize …

//  compare size of timeAttributedStr to window and decrease fontSize if needed
// no idea how to do this
      }
}
}

The Problem:
I want to make fontSize as big as possible. And then do:
if timeAttributedStr.size.width > window.size.width then decrease fontSize

But sadly, AttributedString has no size.

A fixed fontSize is less than ideal, because the optimal timeAttributedStr will depend both on Locale and Watch model.

Gerriet.
Re: SwiftUI AttributedString on Watch

Laurent Daudelin
 

Doesn’t AttributedString uses a dictionary to set its attributes, including font and font size?

-Laurent.
-- 
Laurent Daudelin   laurent@...
Skype: LaurentDaudelin
Logiciels Némésys Software   https://www.nemesys-soft.com/

On Nov 7, 2022, at 07:06, Gerriet M. Denkmann <gerriet@...> wrote:

I have a Watch-App using SwiftUI.

let fontSize = 40.0
struct WatchContentView: View
{
@State var timeAttributedStr = AttributedString("--")
let timer = Timer.publish(every: 1, tolerance: 0.1, on: .main, in: .common).autoconnect()

var body: some View
{
VStack
{
Text(timeAttributedStr)
}
.onReceive(timer)
{ currentTime  in

timeAttributedStr = … make from currentTime using fontSize …

//  compare size of timeAttributedStr to window and decrease fontSize if needed
// no idea how to do this
      }
}
}

The Problem:
I want to make fontSize as big as possible. And then do:
if timeAttributedStr.size.width > window.size.width then decrease fontSize

But sadly, AttributedString has no size.

A fixed fontSize is less than ideal, because the optimal timeAttributedStr will depend both on Locale and Watch model.

Gerriet.
SwiftUI AttributedString on Watch

Gerriet M. Denkmann
 

I have a Watch-App using SwiftUI.

let fontSize = 40.0
struct WatchContentView: View
{
@State var timeAttributedStr = AttributedString("--")
let timer = Timer.publish(every: 1, tolerance: 0.1, on: .main, in: .common).autoconnect()

var body: some View
{
VStack
{
Text(timeAttributedStr)
}
.onReceive(timer)
{ currentTime in

timeAttributedStr = … make from currentTime using fontSize …

// compare size of timeAttributedStr to window and decrease fontSize if needed
// no idea how to do this
}
}
}

The Problem:
I want to make fontSize as big as possible. And then do:
if timeAttributedStr.size.width > window.size.width then decrease fontSize

But sadly, AttributedString has no size.

A fixed fontSize is less than ideal, because the optimal timeAttributedStr will depend both on Locale and Watch model.

Gerriet.
Re: Strange: Rosetta faster than M1

Gary L. Wade
 

If you haven’t already, submit a feedback request with your source, Xcode version, and platform used that demonstrate the issue.
--
Gary

On Sep 22, 2022, at 9:16 PM, Gerriet M. Denkmann <gerriet@...> wrote:


On 23 Sep 2022, at 09:28, Jack Brindle via groups.io <jackbrindle@...> wrote:

For those of us not in that forum, what was the explanation? You have our attention with this one...
Steve Cannon explained that:
• Arm has “madd” which does multiply and add in one go. But has a latency of more than one cycle.
• x86_64 doesn't have a multiply-add instruction.

Using multiply-add is generally a good idea (that’s why the arm compiler choose it), but in a very short loop (as in my case) the added latency sadly makes things slower.
And so the native M1 code ended up being 60 % slower than x86_64 + Rosetta.

Maybe the optimiser for Apple Silicon should consider not using “madd” in very short loops.



On Sep 22, 2022, at 9:26 PM, Gerriet M. Denkmann <gerriet@...> wrote:


On 23 Sep 2022, at 07:51, Quincey Morris <quinceymorris@...> wrote:

OK, this is embarrassing. I’m so used to looking at Swift code these days, that my brain just automatically translated your code into Swift, and I never realized it was C. So the Swift forums aren’t where I should have suggested — although I see over there that you might be gettting some kind of answer anyway. It’s an interesting question.
As you see, I got an excellent in depth answer and also some very helpful tips for improvements.
So no reason to be embarrassed at all.
Rather I have to thank you for a very good and fruitful suggestion.

Gerriet.



On Sep 21, 2022, at 17:49, Quincey Morris <quinceymorris@...> wrote:

I really think you should start by asking this question over in the Swift forums, in case there is some compiler-specific answer that can immediately explain the result. It could be a compiler code generation deficiency, but there are many other possibilities. For example, a colleague of mine speculated that there could be reasons why the M1 Mac ran the Rosetta translation on a *performance* core, but ran the Apple Silicon version on an *efficiency* core.

You can also investigate the performance yourself, by running (say) the Time Profiler template in Instruments. It’s unclear which instrument might provide informative results, so you might need to try a couple of different templates, focussing on different things.

This might ultimately be an Apple support question, but I’d imagine there are numerous people on the Swift forums who’d enjoy puzzling out the answer. :)

On Sep 20, 2022, at 22:59, Gerriet M. Denkmann <gerriet@...> wrote:



On 20 Sep 2022, at 19:42, Alex Zavatone via groups.io <zav@...> wrote:

It might seem like a primitive approach, but logging with time stamps should be able to highlight where the suckyness is. Run a log that displays the time delta from the last logging statement so that you are only looking at the deltas. Then run each version and see where the slowness is. That should tell you, right?
I did this:
typedef uint32_t limb;
typedef uint64_t bigLimb;

const uint len = 50000;
const int shiftLimb = sizeof(limb) * 8;

limb *someArray = malloc( len * sizeof(limb) );
bigLimb someBig = 0;

for (bigLimb factor = 1; factor < len; factor++ )
{
for (uint idx = 0 ; idx < len ; idx++)
{
someBig += factor * someArray[idx] ;
someArray[idx] = (limb)(someBig);
someBig >>= shiftLimb;
}
}

and run it in Release mode (-Os = Fastest, Smallest)
(In Debug mode (-O0) Rosetta time = M1 time).

with "someBig >>= shiftLimb”:
Rosetta M1 Rosetta time / M1 time
1.8 3.35 0.54
without the shift:
1.32 0.924 1.43

So it seems that Rosetta optimizes shifts way better than Apple Silicon.

Which kind of looks like a bug.

Gerriet.
Re: Strange: Rosetta faster than M1

Chris Ridd
 

On 22 Sep 2022, at 01:49, Quincey Morris <quinceymorris@...> wrote:

I really think you should start by asking this question over in the Swift forums, in case there is some compiler-specific answer that can immediately explain the result. It could be a compiler code generation deficiency, but there are many other possibilities. For example, a colleague of mine speculated that there could be reasons why the M1 Mac ran the Rosetta translation on a *performance* core, but ran the Apple Silicon version on an *efficiency* core.
I was wondering about the P/E cores too. Perhaps you can avoid that difference by using GCD + QOS to explicitly run the calculation on the desired kind of core. Though I guess we don’t actually know if Rosetta always runs high QOS Intel threads on high QOS M1 threads..

But yes, Gerriet’s good spot about the use of >>= looks like something for the compiler/codegen folks.

Chris
Re: Strange: Rosetta faster than M1

Gerriet M. Denkmann
 

On 23 Sep 2022, at 09:28, Jack Brindle via groups.io <jackbrindle@...> wrote:

For those of us not in that forum, what was the explanation? You have our attention with this one...
Steve Cannon explained that:
• Arm has “madd” which does multiply and add in one go. But has a latency of more than one cycle.
• x86_64 doesn't have a multiply-add instruction.

Using multiply-add is generally a good idea (that’s why the arm compiler choose it), but in a very short loop (as in my case) the added latency sadly makes things slower.
And so the native M1 code ended up being 60 % slower than x86_64 + Rosetta.

Maybe the optimiser for Apple Silicon should consider not using “madd” in very short loops.



On Sep 22, 2022, at 9:26 PM, Gerriet M. Denkmann <gerriet@...> wrote:



On 23 Sep 2022, at 07:51, Quincey Morris <quinceymorris@...> wrote:

OK, this is embarrassing. I’m so used to looking at Swift code these days, that my brain just automatically translated your code into Swift, and I never realized it was C. So the Swift forums aren’t where I should have suggested — although I see over there that you might be gettting some kind of answer anyway. It’s an interesting question.
As you see, I got an excellent in depth answer and also some very helpful tips for improvements.
So no reason to be embarrassed at all.
Rather I have to thank you for a very good and fruitful suggestion.

Gerriet.



On Sep 21, 2022, at 17:49, Quincey Morris <quinceymorris@...> wrote:

I really think you should start by asking this question over in the Swift forums, in case there is some compiler-specific answer that can immediately explain the result. It could be a compiler code generation deficiency, but there are many other possibilities. For example, a colleague of mine speculated that there could be reasons why the M1 Mac ran the Rosetta translation on a *performance* core, but ran the Apple Silicon version on an *efficiency* core.

You can also investigate the performance yourself, by running (say) the Time Profiler template in Instruments. It’s unclear which instrument might provide informative results, so you might need to try a couple of different templates, focussing on different things.

This might ultimately be an Apple support question, but I’d imagine there are numerous people on the Swift forums who’d enjoy puzzling out the answer. :)

On Sep 20, 2022, at 22:59, Gerriet M. Denkmann <gerriet@...> wrote:



On 20 Sep 2022, at 19:42, Alex Zavatone via groups.io <zav@...> wrote:

It might seem like a primitive approach, but logging with time stamps should be able to highlight where the suckyness is. Run a log that displays the time delta from the last logging statement so that you are only looking at the deltas. Then run each version and see where the slowness is. That should tell you, right?
I did this:
typedef uint32_t limb;
typedef uint64_t bigLimb;

const uint len = 50000;
const int shiftLimb = sizeof(limb) * 8;

limb *someArray = malloc( len * sizeof(limb) );
bigLimb someBig = 0;

for (bigLimb factor = 1; factor < len; factor++ )
{
for (uint idx = 0 ; idx < len ; idx++)
{
someBig += factor * someArray[idx] ;
someArray[idx] = (limb)(someBig);
someBig >>= shiftLimb;
}
}

and run it in Release mode (-Os = Fastest, Smallest)
(In Debug mode (-O0) Rosetta time = M1 time).

with "someBig >>= shiftLimb”:
Rosetta M1 Rosetta time / M1 time
1.8 3.35 0.54
without the shift:
1.32 0.924 1.43

So it seems that Rosetta optimizes shifts way better than Apple Silicon.

Which kind of looks like a bug.

Gerriet.
Re: Strange: Rosetta faster than M1

Jack Brindle
 

For those of us not in that forum, what was the explanation? You have our attention with this one...

Jack

On Sep 22, 2022, at 9:26 PM, Gerriet M. Denkmann <gerriet@...> wrote:



On 23 Sep 2022, at 07:51, Quincey Morris <quinceymorris@...> wrote:

OK, this is embarrassing. I’m so used to looking at Swift code these days, that my brain just automatically translated your code into Swift, and I never realized it was C. So the Swift forums aren’t where I should have suggested — although I see over there that you might be gettting some kind of answer anyway. It’s an interesting question.
As you see, I got an excellent in depth answer and also some very helpful tips for improvements.
So no reason to be embarrassed at all.
Rather I have to thank you for a very good and fruitful suggestion.

Gerriet.



On Sep 21, 2022, at 17:49, Quincey Morris <quinceymorris@...> wrote:

I really think you should start by asking this question over in the Swift forums, in case there is some compiler-specific answer that can immediately explain the result. It could be a compiler code generation deficiency, but there are many other possibilities. For example, a colleague of mine speculated that there could be reasons why the M1 Mac ran the Rosetta translation on a *performance* core, but ran the Apple Silicon version on an *efficiency* core.

You can also investigate the performance yourself, by running (say) the Time Profiler template in Instruments. It’s unclear which instrument might provide informative results, so you might need to try a couple of different templates, focussing on different things.

This might ultimately be an Apple support question, but I’d imagine there are numerous people on the Swift forums who’d enjoy puzzling out the answer. :)

On Sep 20, 2022, at 22:59, Gerriet M. Denkmann <gerriet@...> wrote:



On 20 Sep 2022, at 19:42, Alex Zavatone via groups.io <zav@...> wrote:

It might seem like a primitive approach, but logging with time stamps should be able to highlight where the suckyness is. Run a log that displays the time delta from the last logging statement so that you are only looking at the deltas. Then run each version and see where the slowness is. That should tell you, right?
I did this:
typedef uint32_t limb;
typedef uint64_t bigLimb;

const uint len = 50000;
const int shiftLimb = sizeof(limb) * 8;

limb *someArray = malloc( len * sizeof(limb) );
bigLimb someBig = 0;

for (bigLimb factor = 1; factor < len; factor++ )
{
for (uint idx = 0 ; idx < len ; idx++)
{
someBig += factor * someArray[idx] ;
someArray[idx] = (limb)(someBig);
someBig >>= shiftLimb;
}
}

and run it in Release mode (-Os = Fastest, Smallest)
(In Debug mode (-O0) Rosetta time = M1 time).

with "someBig >>= shiftLimb”:
Rosetta M1 Rosetta time / M1 time
1.8 3.35 0.54
without the shift:
1.32 0.924 1.43

So it seems that Rosetta optimizes shifts way better than Apple Silicon.

Which kind of looks like a bug.

Gerriet.
Re: Strange: Rosetta faster than M1

Gerriet M. Denkmann
 

On 23 Sep 2022, at 07:51, Quincey Morris <quinceymorris@...> wrote:

OK, this is embarrassing. I’m so used to looking at Swift code these days, that my brain just automatically translated your code into Swift, and I never realized it was C. So the Swift forums aren’t where I should have suggested — although I see over there that you might be gettting some kind of answer anyway. It’s an interesting question.
As you see, I got an excellent in depth answer and also some very helpful tips for improvements.
So no reason to be embarrassed at all.
Rather I have to thank you for a very good and fruitful suggestion.

Gerriet.



On Sep 21, 2022, at 17:49, Quincey Morris <quinceymorris@...> wrote:

I really think you should start by asking this question over in the Swift forums, in case there is some compiler-specific answer that can immediately explain the result. It could be a compiler code generation deficiency, but there are many other possibilities. For example, a colleague of mine speculated that there could be reasons why the M1 Mac ran the Rosetta translation on a *performance* core, but ran the Apple Silicon version on an *efficiency* core.

You can also investigate the performance yourself, by running (say) the Time Profiler template in Instruments. It’s unclear which instrument might provide informative results, so you might need to try a couple of different templates, focussing on different things.

This might ultimately be an Apple support question, but I’d imagine there are numerous people on the Swift forums who’d enjoy puzzling out the answer. :)

On Sep 20, 2022, at 22:59, Gerriet M. Denkmann <gerriet@...> wrote:



On 20 Sep 2022, at 19:42, Alex Zavatone via groups.io <zav@...> wrote:

It might seem like a primitive approach, but logging with time stamps should be able to highlight where the suckyness is. Run a log that displays the time delta from the last logging statement so that you are only looking at the deltas. Then run each version and see where the slowness is. That should tell you, right?
I did this:
typedef uint32_t limb;
typedef uint64_t bigLimb;

const uint len = 50000;
const int shiftLimb = sizeof(limb) * 8;

limb *someArray = malloc( len * sizeof(limb) );
bigLimb someBig = 0;

for (bigLimb factor = 1; factor < len; factor++ )
{
for (uint idx = 0 ; idx < len ; idx++)
{
someBig += factor * someArray[idx] ;
someArray[idx] = (limb)(someBig);
someBig >>= shiftLimb;
}
}

and run it in Release mode (-Os = Fastest, Smallest)
(In Debug mode (-O0) Rosetta time = M1 time).

with "someBig >>= shiftLimb”:
Rosetta M1 Rosetta time / M1 time
1.8 3.35 0.54
without the shift:
1.32 0.924 1.43

So it seems that Rosetta optimizes shifts way better than Apple Silicon.

Which kind of looks like a bug.

Gerriet.
Re: Strange: Rosetta faster than M1

Quincey Morris
 

OK, this is embarrassing. I’m so used to looking at Swift code these days, that my brain just automatically translated your code into Swift, and I never realized it was C. So the Swift forums aren’t where I should have suggested — although I see over there that you might be gettting some kind of answer anyway. It’s an interesting question.

Does this mean that Swift is some kind of cult that has taken over my brain? Am I auto translating the entire world into Swift? Can I get rehab for this?

Admittedly, the people who might be interested in this overlap pretty well with Swift engineers, but I’m sorry I didn’t make a better suggestion.

On Sep 21, 2022, at 17:49, Quincey Morris <quinceymorris@...> wrote:

I really think you should start by asking this question over in the Swift forums, in case there is some compiler-specific answer that can immediately explain the result. It could be a compiler code generation deficiency, but there are many other possibilities. For example, a colleague of mine speculated that there could be reasons why the M1 Mac ran the Rosetta translation on a *performance* core, but ran the Apple Silicon version on an *efficiency* core.

You can also investigate the performance yourself, by running (say) the Time Profiler template in Instruments. It’s unclear which instrument might provide informative results, so you might need to try a couple of different templates, focussing on different things.

This might ultimately be an Apple support question, but I’d imagine there are numerous people on the Swift forums who’d enjoy puzzling out the answer. :)

On Sep 20, 2022, at 22:59, Gerriet M. Denkmann <gerriet@...> wrote:



On 20 Sep 2022, at 19:42, Alex Zavatone via groups.io <zav@...> wrote:

It might seem like a primitive approach, but logging with time stamps should be able to highlight where the suckyness is.  Run a log that displays the time delta from the last logging statement so that you are only looking at the deltas. Then run each version and see where the slowness is.  That should tell you, right?

I did this:
typedef uint32_t limb;
typedef uint64_t bigLimb;

const uint len = 50000;
const int shiftLimb = sizeof(limb) * 8;

limb *someArray = malloc( len * sizeof(limb) );  
bigLimb someBig = 0;

for (bigLimb factor = 1; factor < len; factor++ )
{
for (uint idx = 0 ; idx < len ; idx++)
{
someBig += factor * someArray[idx] ;
someArray[idx] = (limb)(someBig);
someBig >>= shiftLimb;
}
}

and run it in Release mode (-Os = Fastest, Smallest) 
(In Debug mode (-O0) Rosetta time = M1 time).

with "someBig >>= shiftLimb”:
Rosetta M1 Rosetta time / M1 time
1.8 3.35 0.54
without the shift:
1.32 0.924 1.43

So it seems that Rosetta optimizes shifts way better than Apple Silicon.

Which kind of looks like a bug.

Gerriet.
Re: Strange: Rosetta faster than M1

Quincey Morris
 

I really think you should start by asking this question over in the Swift forums, in case there is some compiler-specific answer that can immediately explain the result. It could be a compiler code generation deficiency, but there are many other possibilities. For example, a colleague of mine speculated that there could be reasons why the M1 Mac ran the Rosetta translation on a *performance* core, but ran the Apple Silicon version on an *efficiency* core.

You can also investigate the performance yourself, by running (say) the Time Profiler template in Instruments. It’s unclear which instrument might provide informative results, so you might need to try a couple of different templates, focussing on different things.

This might ultimately be an Apple support question, but I’d imagine there are numerous people on the Swift forums who’d enjoy puzzling out the answer. :)

On Sep 20, 2022, at 22:59, Gerriet M. Denkmann <gerriet@...> wrote:



On 20 Sep 2022, at 19:42, Alex Zavatone via groups.io <zav@...> wrote:

It might seem like a primitive approach, but logging with time stamps should be able to highlight where the suckyness is. Run a log that displays the time delta from the last logging statement so that you are only looking at the deltas. Then run each version and see where the slowness is. That should tell you, right?
I did this:
typedef uint32_t limb;
typedef uint64_t bigLimb;

const uint len = 50000;
const int shiftLimb = sizeof(limb) * 8;

limb *someArray = malloc( len * sizeof(limb) );
bigLimb someBig = 0;

for (bigLimb factor = 1; factor < len; factor++ )
{
for (uint idx = 0 ; idx < len ; idx++)
{
someBig += factor * someArray[idx] ;
someArray[idx] = (limb)(someBig);
someBig >>= shiftLimb;
}
}

and run it in Release mode (-Os = Fastest, Smallest)
(In Debug mode (-O0) Rosetta time = M1 time).

with "someBig >>= shiftLimb”:
Rosetta M1 Rosetta time / M1 time
1.8 3.35 0.54
without the shift:
1.32 0.924 1.43

So it seems that Rosetta optimizes shifts way better than Apple Silicon.

Which kind of looks like a bug.

Gerriet.
Re: Strange: Rosetta faster than M1

Gerriet M. Denkmann
 

On 20 Sep 2022, at 19:42, Alex Zavatone via groups.io <zav@...> wrote:

It might seem like a primitive approach, but logging with time stamps should be able to highlight where the suckyness is. Run a log that displays the time delta from the last logging statement so that you are only looking at the deltas. Then run each version and see where the slowness is. That should tell you, right?
I did this:
typedef uint32_t limb;
typedef uint64_t bigLimb;

const uint len = 50000;
const int shiftLimb = sizeof(limb) * 8;

limb *someArray = malloc( len * sizeof(limb) );
bigLimb someBig = 0;

for (bigLimb factor = 1; factor < len; factor++ )
{
for (uint idx = 0 ; idx < len ; idx++)
{
someBig += factor * someArray[idx] ;
someArray[idx] = (limb)(someBig);
someBig >>= shiftLimb;
}
}

and run it in Release mode (-Os = Fastest, Smallest)
(In Debug mode (-O0) Rosetta time = M1 time).

with "someBig >>= shiftLimb”:
Rosetta M1 Rosetta time / M1 time
1.8 3.35 0.54
without the shift:
1.32 0.924 1.43

So it seems that Rosetta optimizes shifts way better than Apple Silicon.

Which kind of looks like a bug.

Gerriet.
Re: Strange: Rosetta faster than M1

Alex Zavatone
 

It might seem like a primitive approach, but logging with time stamps should be able to highlight where the suckyness is. Run a log that displays the time delta from the last logging statement so that you are only looking at the deltas. Then run each version and see where the slowness is. That should tell you, right?

Cheers,
Alex Zavatone

On Sep 19, 2022, at 7:40 PM, Gerriet M. Denkmann <gerriet@...> wrote:



On 19 Sep 2022, at 20:07, Alex Zavatone via groups.io <zav@...> wrote:

What is it doing? We would need to compare the tasks it’s doing so that we could estimate where any slowness would be.
It computes the faculty of 300 000 (i.e. 1 * 2 * 3 * … * 299 999 * 300 000), a somewhat large integer.


Have you profiled it using Xcode’s profiler?
Yes, but I could not see anything unusual.

Can you add log statements so that you can see where the operations are slowed down?
Probably not. But maybe you could tell me, how I can persuade Instruments to use the Rosetta-Version?
Then maybe I could see, where the two versions differ.

Gerriet.
Re: Strange: Rosetta faster than M1

Gerriet M. Denkmann
 

On 19 Sep 2022, at 19:21, Tom Landrum <tomlandrum@...> wrote:

Perhaps something is cached from the first run? Do you get the same results if you reverse the order?
The results are stable and repeatable and do not depend on the order.

Gerriet.
Re: Strange: Rosetta faster than M1

Gerriet M. Denkmann
 

On 19 Sep 2022, at 20:07, Alex Zavatone via groups.io <zav@...> wrote:

What is it doing? We would need to compare the tasks it’s doing so that we could estimate where any slowness would be.
It computes the faculty of 300 000 (i.e. 1 * 2 * 3 * … * 299 999 * 300 000), a somewhat large integer.


Have you profiled it using Xcode’s profiler?
Yes, but I could not see anything unusual.

Can you add log statements so that you can see where the operations are slowed down?
Probably not. But maybe you could tell me, how I can persuade Instruments to use the Rosetta-Version?
Then maybe I could see, where the two versions differ.

Gerriet.
Re: Strange: Rosetta faster than M1

Glenn L. Austin
 

It's a bit unusual for emulated code to run faster, but not impossible.

Depending upon the operation, the order of execution could end up pre-loading values or accessing devices in such a way that the emulated code isn't blocked waiting for a device/memory while the non-emulated code has to wait.

-- 
Glenn L. Austin, Computer Wizard and Race Car Driver         <><
<http://www.austinsoft.com>


On Sep 19, 2022, at 5:21 AM, Tom Landrum <tomlandrum@...> wrote:

Perhaps something is cached from the first run?  Do you get the same results if you reverse the order?

Tom


On Sep 19, 2022, at 7:02 AM, Gerriet M. Denkmann <gerriet@...> wrote:

I have a simple C command line tool.

This takes 16 seconds when I run it in Xcode with “My Mac”.
But only 11 seconds when run with “My Mac (Rosetta)”

How can this be? 
I always assumed that emulating Intel-Code on a M1 must of course be slower than running native M1-Code directly.

Am I making some silly mistake?

Gerriet.
Re: Strange: Rosetta faster than M1

Tom Landrum
 

Perhaps something is cached from the first run? Do you get the same results if you reverse the order?

Tom

On Sep 19, 2022, at 7:02 AM, Gerriet M. Denkmann <gerriet@...> wrote:

I have a simple C command line tool.

This takes 16 seconds when I run it in Xcode with “My Mac”.
But only 11 seconds when run with “My Mac (Rosetta)”

How can this be?
I always assumed that emulating Intel-Code on a M1 must of course be slower than running native M1-Code directly.

Am I making some silly mistake?

Gerriet.
Re: Strange: Rosetta faster than M1

Alex Zavatone
 

What is it doing? We would need to compare the tasks it’s doing so that we could estimate where any slowness would be.

Have you profiled it using Xcode’s profiler? Can you add log statements so that you can see where the operations are slowed down?

Happy Monday,
Alex Zavatone

On Sep 19, 2022, at 7:02 AM, Gerriet M. Denkmann <gerriet@...> wrote:

I have a simple C command line tool.

This takes 16 seconds when I run it in Xcode with “My Mac”.
But only 11 seconds when run with “My Mac (Rosetta)”

How can this be?
I always assumed that emulating Intel-Code on a M1 must of course be slower than running native M1-Code directly.

Am I making some silly mistake?

Gerriet.
Strange: Rosetta faster than M1

Gerriet M. Denkmann
 

I have a simple C command line tool.

This takes 16 seconds when I run it in Xcode with “My Mac”.
But only 11 seconds when run with “My Mac (Rosetta)”

How can this be?
I always assumed that emulating Intel-Code on a M1 must of course be slower than running native M1-Code directly.

Am I making some silly mistake?

Gerriet.
Printing and MacCatalyst

Rick Aurbach
 

My app implements a report-generation function which displays reports in a presented view controller. The view controller includes an Activity Button, which uses UIActivityViewController to present the standard view which (in my case) includes a Print option. [This is the technique I use to provide report printing.] In iOS, this works fine.

However, when running in MacCatalyst, the view produced by this code does not include a Print option. Anyone have any ideas of what I should do? (So far, my web searches have come up empty.)
Re: Signin with Apple, the sample iOS Juice app

Alex Zavatone
 

Apparently, later than iOS 13.x in the Simulator will not bring up 2FA and break Signin with Apple.

Fun times, fun times.

Cheers,
Alex Zavatone

On Jul 19, 2022, at 11:35 AM, Alex Zavatone via groups.io <zav@...> wrote:

Hi.  I’d like to share what I just played with this morning using Apple’s sample code and see if anyone is seeing the same things.  

The sample app on iOS, Juice, is here and is pretty easy to get up and running on a device.  


I’ve seen a few things that seem odd though and am wondering if anyone else has seen the same.

There are entry fields for UI and password, but you don’t use them at all, assuming that you are already logged in to your device using Signin with Apple.

I’ve tested with faceID and touch ID on devices and in a Simulator.

The first time I auth on one device, my given name and surname are returned but never after that.  They are never returned on the iPad 4.  Any idea why?

This runs fine my iOS 14.6 on my iPhone 11 and iPad 4, I’m able to launch it in a Simulator, but can’t make it past the Apple ID password screen with the continue button.  The wait cursor just keeps spinning and I don’t get any 2FA requests on any of my other devices.  

When using the Sim in this case, it also never times out.  

Is anyone able to make it past auth in a Simulator?

Thanks in advance.
Alex Zavatone
1 - 20 of 1478