# Minimum supported development environment **URL:** \ **Category:** Windows\ **Created:** [January 30, 2025, 5:33pm UTC](https://forums.swift.org/t/minimum-supported-development-environment/77565 "2025-01-30T17:33:20Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![compnerd](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/compnerd/32/2165_2.png) [@compnerd](https://forums.swift.org/u/compnerd)\ **Post date:** [January 30, 2025, 5:33pm UTC](https://forums.swift.org/t/minimum-supported-development-environment/77565/1 "2025-01-30T17:33:20Z")
**NOTE** This is related to the _compiler_ and not the runtime. As we start to look towards compiler performance on Windows, one thing that comes up is the idea of a minimum development environment. Beyond just the OS level requirements, requiring a baseline CPU would be helpful. In particular, if we could assume that a baseline of a Haswell uarch (which is pretty close to the baseline support required for Swift on Windows) and generally matches with the Windows 11 requirements, which doesn't seem too restrictive. However, I am tempted to also require suggest that we require AVX2. This is potentially a bit more controversial. This requirement definitely is a bit beyond the Windows 11 requirements, and does exclude some CPUs that Windows 11 supports (e.g. Celeron N6210). The benefit of raising this requirement would be that we could enable additional optimizations for the compiler, e.g. enabling additional SIMD extensions. I would like to hear if this restriction would be something which would be too limiting for users of the toolchain on Windows. CC: @svanimpe ---
**Author:** ![grynspan](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/grynspan/32/15315_2.png) [@grynspan](https://forums.swift.org/u/grynspan)\ **Post date:** [January 30, 2025, 5:42pm UTC](https://forums.swift.org/t/minimum-supported-development-environment/77565/2 "2025-01-30T17:42:28Z")
Haswell is over a decade old, and I'd personally be fine with requiring it as a baseline—I can't imagine trying to compile Swift code on an 11-year-old CPU is going to be very fun. The Celeron N6210, on the other hand, was released in 2021. I have no idea how many Intel sold, but there are lots of people out there with 4-year-old machines that can otherwise run Windows 11 and the Swift toolchain without issue. ---
**Author:** ![compnerd](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/compnerd/32/2165_2.png) [@compnerd](https://forums.swift.org/u/compnerd)\ **Post date:** [January 30, 2025, 5:49pm UTC](https://forums.swift.org/t/minimum-supported-development-environment/77565/3 "2025-01-30T17:49:51Z")
> [@grynspan](#): > > The Celeron N6210, on the other hand, was released in 2021. I have no idea how many Intel sold, but there are lots of people out there with 4-year-old machines that can otherwise run Windows 11 and the Swift toolchain without issue. There in lies the issue - there was a small portion of supported CPUs for Windows 11 which does not support AVX2 but are somewhat recent. Granted, I'd suggest that they are all under powered. ---
**Author:** ![grynspan](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/grynspan/32/15315_2.png) [@grynspan](https://forums.swift.org/u/grynspan)\ **Post date:** [January 30, 2025, 5:51pm UTC](https://forums.swift.org/t/minimum-supported-development-environment/77565/4 "2025-01-30T17:51:41Z")
Not every developer can afford a high-end workstation. Some folks only have the budget for an entry-level machine, and I would hate to exclude them from our community just because of an oddball cost-cutting measure on Intel's part (that the average developer might not even know about!) ---
**Author:** ![compnerd](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/compnerd/32/2165_2.png) [@compnerd](https://forums.swift.org/u/compnerd)\ **Post date:** [January 30, 2025, 6:58pm UTC](https://forums.swift.org/t/minimum-supported-development-environment/77565/5 "2025-01-30T18:58:40Z")
> [@grynspan](#): > > Not every developer can afford a high-end workstation. Some folks only have the budget for an entry-level machine, and I would hate to exclude them from our community just because of an oddball cost-cutting measure on Intel's part (that the average developer might not even know about!) I have the same reservations. To be clear, I am not suggesting that we change the requirements to have a high-end workstation. I am suggesting that we require CPUs that are not ultra-low end. Intel had a series of IoT edge-compute CPUs and some ultra-low-end CPU SKUs that retroactively removed features that have been shipping since 2013. AVX2 was available since around Haswell. The problem is that in 2021 Intel released a set of Pentium Gold, Pentium Silver, and Celeron CPUs that are based on a newer uarch but are missing ISA features (including AVX2). Supporting these CPUs is going to come at a cost of: 1. increased complexity in the build (incurred by the Swift project) 2. possibly increased build times (incurred by the Swift project) 3. increased complexity in the distribution (incurred by the user _and_ the Swift project) As there have been multiple complaints about the Windows toolchain performance, I think that an option might be to be more transparent and state that the Windows toolchains are being optimized for maximal compatibility and not compiler performance. At that point, perhaps it makes sense to have two separate builds, one for compatibility and one for performance that users can select between? ---
**Author:** ![compnerd](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/compnerd/32/2165_2.png) [@compnerd](https://forums.swift.org/u/compnerd)\ **Post date:** [January 30, 2025, 7:04pm UTC](https://forums.swift.org/t/minimum-supported-development-environment/77565/6 "2025-01-30T19:04:10Z")
To be more explicit about the suggested changes, what I was exploring was the change to building mimalloc via CMake rather than msbuild/Visual Studio. The switch to CMake would enable Microsoft's recommended optimizations for X86 targets: 1. Assume a uarch baseline of Haswell 2. Enable AVX2 However, doing that also allows us to reduce the complexity in the build system. More importantly, we then gain control over enabling some other behavioural features: 1. fixed TLS slot (avoids a TLS lookup) 2. enabling additional SIMD usage 3. enabling a mode where the program termination might speed up (this was one of the tricks that mold uses for perceived performance) With the current version of mimalloc changes, we saw a ~4% throughput improvement on WIndows builds. I have a feeling that the additional changes here could yield another 0.5%-1% improvement. @hjyamauchi already has identified another ~1.5% improvements to the compiler, so while the overall improvements here may seem small, collectively, they will add up. ---
**Author:** ![svanimpe](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/svanimpe/32/38963_2.png) [@svanimpe](https://forums.swift.org/u/svanimpe)\ **Post date:** [January 30, 2025, 7:09pm UTC](https://forums.swift.org/t/minimum-supported-development-environment/77565/7 "2025-01-30T19:09:30Z")
For me personally, this is not really an issue. Windows is so bloated that I wouldn't recommend any student use it for development on old machines. Just last month, I refurbished a few old Windows PCs with 4th and 6th generation Intel CPUs, and while they were pretty much unusable with Windows 10, they still work fine with a current version of Ubuntu. ---
**Author:** ![grynspan](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/grynspan/32/15315_2.png) [@grynspan](https://forums.swift.org/u/grynspan)\ **Post date:** [January 30, 2025, 7:13pm UTC](https://forums.swift.org/t/minimum-supported-development-environment/77565/8 "2025-01-30T19:13:38Z")
> [@svanimpe](#): > > Just last month, I refurbished a few old Windows PCs with 4th and 6th generation Intel CPUs, and while they were pretty much unusable with Windows 10, they still work fine with a current version of Ubuntu. For what it's worth, if we adopted such a change on Windows, I don't see why we wouldn't also adopt it on Linux—which would preclude using those older chips on Linux as well. 🫠 ---
**Author:** ![BlueSparrow](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/bluesparrow/32/38500_2.png) [@BlueSparrow](https://forums.swift.org/u/BlueSparrow)\ **Post date:** [January 30, 2025, 8:23pm UTC](https://forums.swift.org/t/minimum-supported-development-environment/77565/9 "2025-01-30T20:23:50Z")
Haswell is probably okay, but AVX2 I'm less keen on. AVX2 instructions are often not present in VMs, for whatever reason. With any of these newer instructions, I'd be happier seeing the performance improvement numbers. How much faster is an AVX2 enabled compiler? ---
**Author:** ![compnerd](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/compnerd/32/2165_2.png) [@compnerd](https://forums.swift.org/u/compnerd)\ **Post date:** [January 30, 2025, 8:26pm UTC](https://forums.swift.org/t/minimum-supported-development-environment/77565/10 "2025-01-30T20:26:42Z")
> [@BlueSparrow](#): > > How much faster is an AVX2 enabled compiler? Looking into actually getting some numbers. > [@BlueSparrow](#): > > AVX2 instructions are often not present in VMs, for whatever reason. Oh, this is interesting! I would've expected AVX2 to be available, less so AVX512. AVX2 has been around since 2013, and the one instruction that comes up often is the faster bit scanning operations. ---
**Author:** ![grynspan](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/grynspan/32/15315_2.png) [@grynspan](https://forums.swift.org/u/grynspan)\ **Post date:** [January 30, 2025, 8:33pm UTC](https://forums.swift.org/t/minimum-supported-development-environment/77565/11 "2025-01-30T20:33:53Z")
> [@compnerd](#): > > Oh, this is interesting! I would've expected AVX2 to be available, less so AVX512. AVX2 has been around since 2013, and the one instruction that comes up often is the faster bit scanning operations. Even Rosetta 2 [doesn't include](https://developer.apple.com/documentation/apple-silicon/about-the-rosetta-translation-environment) AVX2 support: > Rosetta translates all `x86_64` instructions, but it doesn’t support the execution of some newer instruction sets and processor features, such as AVX, AVX2, and AVX512 vector instructions. If you include these newer instructions in your code, execute them only after verifying that they are available. For example, to determine if AVX512 vector instructions are available, use the [`sysctlbyname`](https://developer.apple.com/documentation/kernel/1387446-sysctlbyname) function to check the `hw.optional.avx512f` attribute. (Although the Internet tells me more recent versions of Rosetta 2 _do_ support it. Still looking for any official source on that.) ---
**Author:** ![BlueSparrow](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/bluesparrow/32/38500_2.png) [@BlueSparrow](https://forums.swift.org/u/BlueSparrow)\ **Post date:** [January 30, 2025, 8:34pm UTC](https://forums.swift.org/t/minimum-supported-development-environment/77565/12 "2025-01-30T20:34:06Z")
> [@compnerd](#): > > Oh, this is interesting! I would've expected AVX2 to be available, less so AVX512. AVX2 has been around since 2013, and the one instruction that comes up often is the faster bit scanning operations. So did I when I was trying to improve some physics calculations at work and suddenly our app stopped launching on our VMs! ---
**Author:** ![compnerd](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/compnerd/32/2165_2.png) [@compnerd](https://forums.swift.org/u/compnerd)\ **Post date:** [January 30, 2025, 8:37pm UTC](https://forums.swift.org/t/minimum-supported-development-environment/77565/13 "2025-01-30T20:37:01Z")
Rosetta 2 and VMs not supporting are a good argument against enabling AVX2 currently, even if it were to give a reasonable speedup I think. Having a more optimized version is still interesting, but I don't know how to support that without a significant cost for build times, download times, and complexity in testing/maintaining the toolchian. ---
**Author:** ![grynspan](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/grynspan/32/15315_2.png) [@grynspan](https://forums.swift.org/u/grynspan)\ **Post date:** [January 30, 2025, 8:51pm UTC](https://forums.swift.org/t/minimum-supported-development-environment/77565/14 "2025-01-30T20:51:37Z")
I spoke with a colleague and they let me know that as of macOS Sequoia, Rosetta 2 _does_ support AVX and AVX2, but not AVX512. I've let our documentation team know to update that article (143910888). ---
**Author:** ![Cyberbeni](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/cyberbeni/32/46241_2.png) [@Cyberbeni](https://forums.swift.org/u/Cyberbeni)\ **Post date:** [January 30, 2025, 10:09pm UTC](https://forums.swift.org/t/minimum-supported-development-environment/77565/15 "2025-01-30T22:09:32Z")
> [@grynspan](#): > > For what it's worth, if we adopted such a change on Windows, I don't see why we wouldn't also adopt it on Linux—which would preclude using those older chips on Linux as well. 🫠 I think people running a low power, low cost, often old, Linux servers at home is way more common. Like I have one with a J4105 and also do slight modifications of docker images from time to time and rebuild them. Compile time being 10 seconds or 5 minutes doesn't really matter if it only happens occasionally. ---
**Author:** ![Jean-Daniel](https://avatars.discourse-cdn.com/v4/letter/j/977dab/32.png) [@Jean-Daniel](https://forums.swift.org/u/Jean-Daniel)\ **Post date:** [January 30, 2025, 11:11pm UTC](https://forums.swift.org/t/minimum-supported-development-environment/77565/16 "2025-01-30T23:11:06Z")
Is rosetta really a concern ? I mean, who is going to use a x86 toolchain on macOS with Apple Silicon, while there is a ARM64 build available ? ---
**Author:** ![grynspan](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/grynspan/32/15315_2.png) [@grynspan](https://forums.swift.org/u/grynspan)\ **Post date:** [January 31, 2025, 1:24am UTC](https://forums.swift.org/t/minimum-supported-development-environment/77565/17 "2025-01-31T01:24:05Z")
It's just a data point. Data points are good to have. We unfortunately don't have a lot of them to tell us how many developers or prospective developers might be impacted by the proposed change. If there are CI systems out there using virtualization or emulation that does not support AVX, that would be a problem. @BlueSparrow pointed this out and I shared the (tangentially) relevant data I had available. 🙃 ---
**Author:** ![compnerd](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/compnerd/32/2165_2.png) [@compnerd](https://forums.swift.org/u/compnerd)\ **Post date:** [January 31, 2025, 1:48am UTC](https://forums.swift.org/t/minimum-supported-development-environment/77565/18 "2025-01-31T01:48:38Z")
> [@Jean-Daniel](#): > > Is rosetta really a concern ? It is a valid point of comparison. However, it _can_ be a concern. What if there is a X64 specific issue that we encounter and the developer needs to run that under rosetta because that is the hardware/environment on hand? > [@Jean-Daniel](#): > > I mean, who is going to use a x86 toolchain on macOS with Apple Silicon, while there is a ARM64 build available ? Until quite recently, the ARM64 toolchain was broken again due to insufficient testing. While the underlying issue of testing hasn't been resolved, the X64 toolchain did provide a temporary stop gap. Just to re-iterate, the point of this conversation was to collect data points as @grynspan points out. We are trying to make a calculation on whether this tradeoff is justified or not based on the data that is available. Breaking CI systems is a real concern that @BlueSparrow pointed out - one that had been missed. This type of feedback is valuable and helpful in making decisions like this which have a broad impact. ---
**Author:** ![Jon\_Shier](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jon_shier/32/921_2.png) [@Jon\_Shier](https://forums.swift.org/u/Jon_Shier)\ **Post date:** [January 31, 2025, 4:40am UTC](https://forums.swift.org/t/minimum-supported-development-environment/77565/19 "2025-01-31T04:40:36Z")
Rosetta is also useful for Linux virtualization on macOS, to help run x86 binaries in ARM Linux VMs. > **[Accelerating the performance of Rosetta | Apple Developer Documentation](https://developer.apple.com/documentation/virtualization/accelerating-the-performance-of-rosetta)** > > Improve Rosetta performance by adding support for the total store ordering (TSO) memory model to your Linux kernel. ---
**Author:** ![scanon](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/scanon/32/2445_2.png) [@scanon](https://forums.swift.org/u/scanon)\ **Post date:** [January 31, 2025, 1:44pm UTC](https://forums.swift.org/t/minimum-supported-development-environment/77565/20 "2025-01-31T13:44:52Z")
> [@Jean-Daniel](#): > > I mean, who is going to use a x86 toolchain on macOS with Apple Silicon, while there is a ARM64 build available ? Most of the core compiler contributors when trying to reproduce an x86-specific bug report, since most of their primary day-to-day work machines are AS. (Happily Rosetta supports AVX2 now, as mentioned upthread) [Next page](https://forums.swift.org/t/minimum-supported-development-environment/77565.md?page=2)