Apple is announcing new iPhone models today. The iPhone 11 uses an Apple A13 Bionic system-on-a-chip. It is a nice improvement over the A12 Bionic in the iPhone XR, XS and XS Max.
But how much faster exactly? Apple first said it is making the fastest GPU and CPU for a smartphone. It then showed two charts with no X-axis — those charts weren’t helpful. But later in the conference, Apple shared some details about A13 Bionic performance.
VP of Silicon Engineering Sri Santhanam shared some details about the A13 Bionic. Everything has been optimized for machine learning. The CPU can do 1 trillion operations per second. The CPU, GPU and Neural Engine should work better together when it comes to performing machine learning tasks.
“The iPhone 11 Pro is the best machine learning platform in any smartphone” Santhanam said.
When it comes to architecture, Apple is using 7nm transistors (like on the A12 Bionic), and there are now 8.5 billion transistors — that’s a huge update compared to the A12 Bionic, which had 6.9 billion transistors. The A13 Bionic still has four high-efficiency cores and two high-performance cores.
The two high-performance cores are 20% faster than previous high-performance cores and consume 30% less battery. The four high-efficiency cores are 20% faster and consume 40% less power.
The GPU has been optimized for Metal. It is 20% faster and consumes 40% less power. And, finally, the neural engine has eight cores and is 20% faster while consuming 15% less power.
The article has been updated with performance details about the A13 Bionic.
On the back of the iPhone 11 Pro can be found three cameras. Why? Because …
This week, Microsoft announced several more features trickling down to Edge Stable from its Beta insider channel. These features include Startup Boost, Sleeping Tabs, Vertical Tabs, and a more navigable History dialog. The company also announced some welcome interface tweaks to Bing—which Microsoft insists on categorizing as Edge features, but these items seem to apply equally to Bing in any browser so far.
If you’re not familiar with Microsoft Edge’s release and download system, there are three Insider channels (Canary, Dev, and Beta) that represent daily, weekly, and six-weekly updates in increasing order of stability. New features debut there before eventually making their way into Stable, where normal users will encounter them.
If you’re a Windows user, you can’t actually download new builds in the Stable channel directly. Instead, you must either look for them in Windows Update or navigate to edge://settings/help in-browser and ask Edge to check for updates to itself. If you’d also like to check out the Edge Insider builds, you can do so safely—they won’t replace your Edge Stable; they install side-by-side, with separate icons on your taskbar making them easy to distinguish.
Edge’s new Startup Boost feature is pretty simple. Instead of killing all processes when you close the browser, it leaves a minimal set open and running. Microsoft says that these always-on background processes decrease Edge launch times—whether opened from an Edge icon or opened automatically as an association with hyperlinks from other applications—by 29% to 41%.
Microsoft also says that the background processes have very little impact on CPU and memory footprint of the system as a whole. The new feature is enabled by default in Edge Stable Build 89, but if you don’t like it, you can disable it on your system—go to edge://settings/system and disable Continue running background apps when Microsoft Edge is closed.
Edge’s new Sleeping Tabs feature automatically puts tabs to sleep—building upon Chromium’s “tab freezing” feature—after two hours of background status without interaction. You can adjust this timeout period manually if it’s not right for you, and Edge also uses heuristics to detect cases when sleep might be inappropriate (for example, tabs that are streaming music in the background).
You can see which tabs have gone to sleep due to their faded appearance in the tab bar; clicking a sleeping tab wakes it up and brings it back into the foreground. To our disappointment, there’s no option to right-click a tab and put it to sleep manually yet—all you can do is wait for the browser to do it for you after a sufficiently long inactivity period.
Vertical tabs—a feature we first reported nearly a year ago—finally made it to release this week in Edge Stable 89.
Modern displays generally have nearly twice as much horizontal screen real estate as vertical, and arranging tabs, application icons, and so forth across the display’s horizontal axis rather than its vertical makes more efficient use of the working space you have.
Edge certainly isn’t the first application to notice this fact—Ubuntu began using a vertical application launcher (its equivalent to the Windows taskbar) by default almost 10 years ago, for one example. We’ve found that the more efficient use of screen real estate is a great idea, but many users have an immediate, strong negative reaction to such a basic change to their navigation concepts.
Probably for that reason, Microsoft left the default tab bar orientation horizontal. If you’d like to browse like it’s 2021, though, the new vertical tab bar is a single click away—as is putting it back the way you found it.
Edge’s new History Hub is another welcome UX update, and it’s simpler to use than it is to describe. Navigating to History from the hamburger menu (or hitting the Ctrl+H hotkey) opens your browsing history as a drop-down menu rather than a full page.
The drop-down History menu also has a stickpin icon on its upper right—clicking the pin dynamically resizes the browser pane, making room for a persistent, pinned History pane to its right. The History pane remains in place and is visible as you navigate the web, whether through links in pages or clicking the History links themselves. This makes it much easier to find what you’re looking for in the recent past.
Rounding out the goodies this week, Microsoft announced some updates to how it displays search results. These updates were also billed as Edge improvements, but when we checked bing.com in Google Chrome on a Linux workstation, we saw the same results there.
Local search results in Bing will begin showing stickpins on a map, dynamically updated as you browse them. This makes it easier to sort your search results by geographical area—which isn’t always as simple as “what’s closest” or “what’s furthest away.” This feature isn’t fully implemented yet; Microsoft says it will be fully available in the US in the coming weeks.
The search engine is also adapting its search results contextually when it understands the broad category of what you’re searching for in the first place. Carousel results for recipes now include dynamically updated panes showing caloric information alongside the picture and meta text of the recipe, for one example. Documentary film search results are another good showcase for this update. They pop up in tiles showing box art, title, and little else; hovering over each tile slides open further detailed information about the film.
Finally, educational searches may give more easily digestible, infographic-style returns instead of the simple dense-text based output we’ve become familiar with in the last two decades. It’s not clear exactly what topics will or will not receive the infographic returns or how those are generated, but Microsoft showcases the result of a Bing search for “giraffe animal” as one example.
Microsoft has released a new version of source-code editor Visual Studio Code that runs natively on Apple Silicon Macs like the MacBook Air, MacBook Pro, and Mac mini models with Apple M1 chips.
The change came in Visual Studio Code 1.54 (now 1.54.1 thanks to a bug fix update), which is available as a universal 64-bit binary, as is standard for apps with Apple Silicon support. That said, Microsoft also offers downloads for x86-64 and Arm64 versions specifically, if desired.
There are no differences in features between the two versions, of course. And the non-Apple Silicon version worked just fine on M1 Macs previously via Rosetta, but Microsoft says M1 users can expect a few optimizations with the new binaries:
We are happy to announce our first release of stable Apple Silicon builds this iteration. Users on Macs with M1 chips can now use VS Code without emulation with Rosetta, and will notice better performance and longer battery life when running VS Code. Thanks to the community for self-hosting with the Insiders build and reporting issues early in the iteration.
Other key features in Visual Studio Code 1.54 include the ability to retain terminal processes on window reload, performance improvements in the Windows version, product icon themes, improvements when viewing Git history timeline entries, and various accessibility improvements.
This is the latest in a slow march of productivity and power user apps that have launched native Apple Silicon versions, such as Adobe Photoshop. But many popular apps are still not native, including Visual Studio Code’s IDE sibling, Visual Studio 2019 for Mac.
However, native Apple Silicon support is expected to come to Visual Studio 2019 for Mac with .NET 6, which is expected to ship in November. The first .NET 6 preview was distributed last month.
Many makers of development and creative production software have committed to releasing Apple Silicon versions of apps, including Adobe and Unity. But others, like Autodesk, haven’t made much noise about Apple Silicon support yet.
Apple is expected to shift its entire Mac lineup to the new architecture by the end of 2022. Reports citing people familiar with Apple’s plans have indicated that more Apple Silicon-based MacBook Pros are coming this year, as well as significant redesigns for both the iMac and MacBook Air, which will also have Apple Silicon chips.
In a message to the Linux Kernel Mailing List yesterday, founding developer Linus Torvalds warned the world not to use the 5.12-rc1 kernel in his public git tree.
Hey peeps – some of you may have already noticed that in my public git tree, the “v5.12-rc1” tag has magically been renamed to “v5.12-rc1-dontuse”. It’s still the same object, it still says “v5.12-rc1” internally and it is still is signed by me, but the user-visible name of the tag has changed.
As it turns out, when Linus Torvalds flags some code dontuse, he really means it—the problem with this 5.12 release candidate broke swapfile handling in a very unpleasant way. Specifically, the updated code would lose the proper offset pointing to the beginning of the swapfile. Again, in Torvalds’ own words, “swapping still happened, but it happened to the wrong part of the filesystem, with the obvious catastrophic end results.”
If your imagination is insufficient, this means that when the kernel paged contents of memory out to disk, the data would land on random parts of the same disk and partition the swapfile lived on… not as files, mind you, but as garbage spewed directly to raw sectors on the disk. This means overwriting not only data in existing files, but also rather large chunks of metadata whose corruption would likely render the entire filesystem unmountable and unusable.
Torvalds goes on to point out that if you aren’t using swap at all, this problem wouldn’t bite you. And if you’re using swap partitions, rather than swap files, you’d be similarly unaffected. Unfortunately, he then reminds us that while he knows an absolute ton about the kernel, he isn’t necessarily all that familiar with all the plumbing a normal end user is concerned with:
And, as far as I know, all the normal distributions set things up with swap partitions, not files, because honestly, swapfiles tend to be slower and have various other complexity issues.
Many distributions still default to swap partitions, rather than files. But Ubuntu—which is perhaps the single most widely deployed Linux distribution on the planet—has been installing swapfiles by default for more than four years now. If you’re an Ubuntu user (or user of an Ubuntu-derived distro, such as Mint), you’ve probably got a swapfile, and this bug would probably trash your entire root filesystem.
Torvalds’ warning matters above and beyond what individual users might do with a release candidate kernel, however. It’s even more important that kernel developers not base their own work around that release and potentially carry a very nasty bug forward further down the line.
I want to make sure that nobody starts new topic branches using that 5.12-rc1 tag. I know a few developers tend to go “Ok, rc1 is out, I got all my development work into this merge window, I will now fast-forward to rc1 and use that as a base for the next release”. Don’t do it this time. It may work perfectly well for you because you have the common partition setup, but it can end up being a horrible base for anybody else that might end up bisecting into that area.
This also leads into one of my own rather frequent warnings to fellow Linux users: don’t blindly leap ahead into cowboy code that hasn’t yet been sufficiently tested. Linux kernel release candidates are usually very, very solid, and it’s tempting to dive into new features as early as possible—but doing so can have very, very ugly consequences. And many of those consequences could have been avoided by waiting for the code to enter production status in the first place.