Skip Navigation

InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)BO
Posts
1
Comments
970
Joined
2 yr. ago

  • macOS converts x86 code to ARM ahead of launching an app, and then caches the translation. It adds a tiny delay to the first time you launch an x86 app on ARM. It also does on-the-fly translation if needed, for applications that do code generation at runtime (such as scripting languages with JIT compilers).

    The biggest difference is that Apple has added support for an x86-like strong memory model to their ARM chips. ARM has a weak memory model. Translating code written for a strong memory model to run on a CPU with a weak memory model absolutely kills performance (see my other comment above for details).

  • Any program written for the .net clr ought to just run out of the box.

    Both of them?

    There’s also an x64 to ARM translation layer that works much like Apple’s Rosetta.

    Except for the performance bit.

    ARM processors use a weak memory model, whereas x86 use a strong memory model. Meaning that x86 guarantees actual order of writes to memory is the same as the order in which those writes executes, while ARM is allowed to re-order them.

    Usually it doesn’t matter in which data is written to RAM, and allowing for re-ordering of writes can boost performance. When it does matter, a developer can insert a so-called memory barrier, this ensures all writes before the barrier are finished before the code continues.

    However, since this is not necessary on x86 as all writes are ordered x86 code does not include these memory barrier instructions at the spots where write order actually matters. So when translating x86 code to ARM code, you have to assume write order always matters because you can’t tell the difference. This means inserting memory barriers after every write in the translated code. This absolutely kills performance.

    Apple includes a special mode in their ARM chips, only used by Rosetta, that enables an x86-like strong memory model. This means Rosetta can translate x86 to ARM without inserting those performance-killing memory barriers. Unless Qualcomm added a similar mode (and AFAIK they did not) and Microsoft added support for it in their emulator, performance of translated x86 code is going to be nothing like that of Rosetta.

  • The longer story is it's actually best to stop charging your phone at 80 percent unless you really need the extra juice, because any time your phone spends above that is potentially damaging, but that tends to be hard to deal with for most people.

    iPhones handle this automatically if you enable ‘optimized charging’. They charge to 80% and keep it there until just before you need to take the phone off the charger (they base this on your alarm and some on-device machine learning stuff to predict when you will pull it off the charger in the morning). It then charges to 100% just in time, so the battery spends as little time as possible above 80%.

  • Having to pay one off the most profitable companies in the world before I can provide that service seems weird.

    So your argument is that because Apple is very profitable they should give you free shit?

    Like charging charity workers for the privilege of helping.

    You realize that charity workers have to pay for all kinds of things, right?

  • Some capabilities actually need a paid developer account even if you don’t plan to put the app on the store.

    Sure, but that is for capabilities where it makes sense. For example if your app wants to use iCloud.

  • Signed, a disabled and unable to work guy who enjoys IT and programing

    You don’t need to pay to develop an app, you only need to pay to put it in the store.

    So develop your app. If it’s any good, pay the $100, sell it in the store and it’ll pay for itself. It may even make you a little profit. If it’s not good enough for that, why does it need to be in the store?

  • Say you you're maintaining a FOSS app on your own time. How interested would you be to pay Apple $100 annually for the privilege of giving their users free stuff?

    Depends on the reason you’re maintaining that app to begin with. If it’s a hobby, then $100/year is a pretty cheap hobby.

  • Good for you you have so much disposable income. Many hobby devs such as myself aren’t so lucky

    Go talk to some random people and ask them how much they spend on their hobbies, I bet you won't find many people who have a hobby that costs less than $100/year. It's a damn cheap hobby.

    which is one reason why I don’t make Apple apps.

    That's probably a good thing. I don't think we need more apps made by amateurs in the app store.

  • I said small, synonyms hobby, FOSS. It is an obstacle to be forced to pay money to Apple for the 'privelidge' of being able to install it on their devices.

    It’s $100, basically a symbolic amount.

  • What is arbitrary about it? Porting the iOS developer tools to Windows would be an enormous amount of work with little benefit.

    Developer time is expensive, hardware is cheap.

  • Why do you consider it an issue?

    Let me put it this way: if the costs of buying a Mac is too much, you certainly can’t afford the developer that needs to use that Mac. The cost of the hardware is such a tiny part of the total cost of developing an app that it’s laughable to consider it a major obstacle.

  • if you’re sending high wattage through it there’s a real possibility you’re gonna burn some to kind up.

    Anything over 3A or 60W requires the cable to have an e-marker. A little chip inside one of the connectors that indicates what the cable is capable of. No USB certified device should try to pull 60W or more through a cable without e-marker or anything above what the cable can handle if it does have a marker.

  • Laten we het hopen van niet. Het is eigenlijk best belachelijk dat we als zo’n klein landje een eigen taal hebben. Ik kan eigenlijk ook geen voordelen bedenken van het hebben van een eigen taal. Wel een heleboel nadelen.

  • open standard.

    Which is why it’s such a mess. The RCS standard is defined by the GSM association, an organization with well over a thousand members. Want to add a feature to RCS? Prepare for years of bureaucracy trying to get the standard amended. Then 750+ mobile operators worldwide need to upgrade their systems, adding at least another few years.

    Meanwhile when Apple wants to add a feature they can just roll it out in the next iOS release.

  • Agreed, but not requiring labeling or some sort of method to identify was a real fuckup on their part.

    Yeah, we used to have that. It was great. They even made it so you couldn’t even fit the wrong cable in a port. They did that by having different connectors for different cables.