Jump to content

Search the Community

Showing results for tags 'apple silicon m1'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Site Related
    • News & Updates
    • Site / Forum Feedback
    • Member Introduction
  • News
    • General News
    • FileSharing News
    • Mobile News
    • Software News
    • Security & Privacy News
    • Technology News
  • Downloads
    • nsane.down
  • General Discussions & Support
    • Filesharing Chat
    • Security & Privacy Center
    • Software Chat
    • Mobile Mania
    • Technology Talk
    • Entertainment Exchange
    • Guides & Tutorials
  • Off-Topic Chat
    • The Chat Bar
    • Jokes & Funny Stuff
    • Polling Station

Categories

  • Drivers
  • Filesharing
    • BitTorrent
    • eDonkey & Direct Connect (DC)
    • NewsReaders (Usenet)
    • Other P2P Clients & Tools
  • Internet
    • Download Managers & FTP Clients
    • Messengers
    • Web Browsers
    • Other Internet Tools
  • Multimedia
    • Codecs & Converters
    • Image Viewers & Editors
    • Media Players
    • Other Multimedia Software
  • Security
    • Anti-Malware
    • Firewalls
    • Other Security Tools
  • System
    • Benchmarking & System Info
    • Customization
    • Defrag Tools
    • Disc & Registry Cleaners
    • Management Suites
    • Other System Tools
  • Other Apps
    • Burning & Imaging
    • Document Viewers & Editors
    • File Managers & Archivers
    • Miscellaneous Applications
  • Linux Distributions

Categories

  • General News
  • File Sharing News
  • Mobile News
  • Software News
  • Security & Privacy News
  • Technology News

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Found 3 results

  1. The new M1 Macs are now arriving to customers, and one of the first people to get the new M1 13-inch MacBook Pro with 8-core CPU, 8-core GPU, and 8GB unified memory has run a much anticipated R23 Cinebench benchmark on the 8GB 13-inch MacBook Pro with 512GB of storage to give us a better idea of performance. Cinebench is a more intensive multi-thread test than Geekbench 5, testing performance over a longer period of time, and it can provide a clearer overview of how a machine will work in the real world. The M1 MacBook Pro earned a multi-core Cinebench score of 7508, and a single-core score of 1498, which is similar in performance to some of Intel's 11th-generation chips. Comparatively, a 2019 16-inch MacBook Pro with 2.3GHz Core i9 chip earned a multi-core score of 8818, according to a MacRumors reader who benchmarked his machine with the new R23 update that came out last week. The 2.6GHz low-end 16-inch MacBook Pro earned a single-core score of 1113 and a multi-core score of 6912 on the same test, and the high-end prior-generation MacBook Air earned a single-core score of 1119 and a multi-core score of 4329. Other Cinebench R23 scores can be found on the CPU Monkey website for both multi-core and single-core performance. It's worth noting that the new M1 Macs are lower performance machines that aren't meant for heavy duty rendering tasks. The M1 MacBook Pro replaces the low-end machine, while the ‌MacBook Air‌ has always been more of a consumer machine than a Pro machine. Apple does have plans for higher-end Pro machines with Apple Silicon chips, but the company has said that it will take around two years to transition the entire Mac lineup to Arm-based chips. The Cinebench scores for the ‌MacBook Air‌ bode well for future Macs that are expected to get even higher performance M-series chips. Source
  2. The excitement around Apple’s new M1 chip is everywhere. I bought a MacBook Air 16GB M1 to see how viable it is as main development machine - here’s an early report after a week of testing. Xcode Xcode runs FAST on the M1. Compiling the PSPDFKit PDF SDK (debug, arm64) can almost compete with the fastest Intel-based MacBook Pro Apple offers to date, with 8:49 min vs 7:31 min. For comparison, my Hackintosh builds the same in less than 5 minutes. One can’t overstate how impressive this is for a fan-less machine. Apple’s last experiment with fan-less MacBooks was the 12-inch version from 2017, which builds the same project in 41 minutes. Our tests mostly ran just fine, although I found a bug specific to arm64 that we missed before, as we don’t run our tests on actual hardware on CI. Moving the Simulator to the same architecture as shipping devices will be beneficial and will help find more bugs. Testing iOS below 14 is problematic. It seems WebKit is crashing in a memory allocator, throwing EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0) (Apple folks: FB8920323). Performance also seems really bad, with Xcode periodically freezing and the whole system becoming so slow that the mouse cursor gets choppy. Some Simulators even make problems on iOS 14, such as the iPad Air (4th gen) which still emulates Intel, so try to avoid that one. We were extremely excited to be moving our CI to Mac Mini’s with M1 chip and are waiting on MacStadium to release devices, however it seems we will have to restrict tests to iOS 14 for that to work. With our current schedule, we plan to drop iOS 12 in Q3 2021 and iOS 13 in Q3 2022, so it will be a while until we can fully move to Apple Silicon. There is a chance that Apple fixes these issues, however it’s not something to count on - given that this only affects older versions of iOS, the problem will at some point just “go away”. Update: We’re working around the WebKit crashes for now via detecting Rosetta2 translation at runtime and simply skipping the tests where WebKit is used. This isn’t great, but luckily we’re not using WebKit a lot in our current project. See my Gist for details. Performance seems acceptable if you restrict parallel testing to at most two instances - else the system simply runs out of RAM and swapping is just really slow. Docker We use Docker to automate our Website and load environments for our Web and Server PDF SDKs. Docker posted a status update blog post about the current state of things, admitting that it currently won’t work but that they’re working on it. There are more hacky ways to use Apple’s Hypervisor to run Docker container manually, however this needs arm-based containers. I expect a solution in Q1 2021 that runs arm-based containers. We’ll have to do some work to add arm-support (something already on the roadmap) so this is only a transitional issue. Virtualization and Windows To test our Windows PDF SDK, most folks are using a VMware virtual machine with Windows 10 and Visual Studio. Currently none of the Mac virtualisation solutions support Apple Silicon, however both VMware and Parallels are working on it. I do not expect Virtualbox to be updated anytime soon. I expect that eventually we’ll be able to run ARM-based Windows with commercial tooling. Various proof-of-concepts already exist, and performance seems extremely promising. Microsoft currently doesn’t sell ARM-based Windows, so getting a license will be interesting. ARM-Windows can emulate x86 applications, and Microsoft is working on x64 emulation, which is already rolling out in Insider builds. In a few months, it should be possible to develop and test our Windows SDK with Visual Studio on M1 in reasonable performance. Running older versions of macOS might be more problematic. We currently support macOS 10.14 with our AppKit PDF SDK and macOS 10.15 with the Catalyst PDF SDK, both OS releases that require testing. It remains to be seen if VMWare or Parallels include a complete x64 emulation layer. This would likely be really slow, so I wouldn’t count on it. Lastly, 16 GB RAM just isn’t a lot. When running parallel tests, the machine starts to heavily swap and performance really goes down the drain. This will be even more problematic with virtual machines running. Future machines will offer 32 GB options to alleviate this issue. Update: How to run Windows 10 on ARM in Qemu with Hypervisor.framework patches on Apple Silicon Mac Android Studio IntelliJ is working on porting the JetBrains Runtime to Apple Silicon. The apps currently work through Rosetta 2, however building via Gradle is extremely slow. Gradle creates code at runtime, which seems a particular bad combination with the Rosetta 2 ahead-of-time translation logic. I expect that most issues will be solved by Q1 2021, however it will likely be some more time until all Java versions run great on ARM. A lot of effort has been put into loop unrolling and vectorisation, not everything there is available on ARM just yet. Update: Azul offers macOS JDKs for arm64, including for Java 8. Homebrew Homebrew currently works via Rosetta 2. Just prefix everything with arch -x86_64 and it’ll just work. It is possible to install an additional (arm-based) version of Homebrew under /opt/homebrew and mix setup, as more and more software is adding support for arm. This is not a problem currently (performance is good) and will eventually just work natively. Applications Most applications just work, Rosetta is barely noticeable. Larger apps to take a longer initial performance hit (e.g. Microsoft Word takes around 20 seconds until everything is translated), but then these binaries are cached and subsequent runs are fast. There’s the occasional app that can’t be translated and fails on startup (e.g. Beamer or the Google Drive “Backup and Sync” client), but this is rare. Some apps are confused about their place on disk and ask to be moved to the Applications directory, when really it’s just the translated binary that runs somewhere else. Most of these dialogs can be ignored. Some apps (e.g. Visual Studio Code) block auto-updating as the translated app location is readonly. However, in case of VS Code, the Insider build is already updated to ARM and just works. Electron-based apps are slow if they run on Rosetta. It seems the highly optimized V8 JavaScript compiler blocks ahead-of-time translation. The latest stable version of Electron (Version 11) already fully supports Apple Silicon, and companies like Slack already updated their beta version to run natively. Google just shipped Chrome that runs on ARM, however there’s still quite a performance gap between it and Apple Safari, which just flies on Apple Silicon. Conclusion The new M1 MacBooks are fast, beautiful and silent and the hype is absolutely justified. There’s still a lot to do on the software-front to catch up, and the bugs around older iOS Simulators are especially problematic. All of that can be fixed in software and the whole industry is currently working on making the experience better, so by next year, when Apple updates the 16-inch MacBook Pro and releases the next generation of their M chip line, it should be absolutely possible to use a M1 Mac as main dev machine. For the time being, the M1 will be my travel secondary laptop, and I’ll keep working on the 2,4 GHz 16-inch MacBook Pro with 32 GB RAM, which just is the faster machine. I’ll be much harder to accept the loud, always-on fans though, now that I know what soon will be possible. Source
  3. Mac Malware 'XCSSET' Adapted for Devices With M1 Chips An increasing number of Mac malware developers have started creating variants that are specifically designed to run on devices powered by Apple’s M1 chip. Apple unveiled its M1 system-on-chip in November 2020 and the first malware created specifically for systems with the arm64 CPU architecture used by the M1 was apparently created in December. This was a variant of Pirrit, a piece of adware that has been around for several years. A few days after the existence of this Pirrit variant came to light, managed detection and response firm Red Canary reported identifying a mysterious piece of Mac malware that had infected tens of thousands of devices around the world. This malware, named Silver Sparrow, also had a variant specifically designed for M1 systems. Kaspersky reported on Friday that it too has spotted a piece of malware with a variant compiled for devices with M1 chips, specifically a variant of the malware known as XCSSET. XCSSET is a mysterious piece of malware first detailed by Trend Micro and Mac security company Intego in August 2020. It does not appear to have been linked to any known threat group or activity, but a majority of infections spotted at the time were in China and India. The malware is designed to allow its operator to launch ransomware attacks (i.e. encrypt files and display a ransom note), and steal information from infected devices, including data associated with the Evernote, Skype, Notes, QQ, WeChat, and Telegram apps. It can also launch universal cross-site scripting (UXSS) attacks in an effort to inject arbitrary JavaScript code into the websites visited by the victim. This allows it to modify sites, including replacing cryptocurrency addresses, and phish credentials and payment card information. XCSSET spreads through code injected into projects for Xcode, Apple’s integrated development environment. The payload is executed when the project is built. Kaspersky has seen an XCSSET sample compiled for the arm64 architecture. This sample was uploaded to the VirusTotal malware analysis service on February 24, which has led the company’s researchers to believe that the campaign is likely still ongoing. Kaspersky noted that in many cases Mac malware is delivered in the Mach-O format, which includes the malicious code compiled for several architectures — depending on what type of device the malware lands on, the code corresponding to that architecture is executed. “With the new M1 chip, Apple has certainly pushed its performance and energy saving limits on Mac computers, but malware developers kept an eye on those innovations and quickly adapted their executables to Apple Silicon by porting the code to the ARM64 architecture,” Kaspersky researchers wrote in a blog post. They added, “We have observed various attempts to port executables not just among typical adware such as Pirrit or Bnodlero samples, but also among malicious packages, such as the Silver Sparrow threat and XCSSET downloadable malicious modules. This certainly will give a kickstart to other malware adversaries to begin adapting their code for running on Apple M1 chips.” Source: Mac Malware 'XCSSET' Adapted for Devices With M1 Chips
×
×
  • Create New...