-
It was a bit more complicated than that: the issue was that one of the early big.LITTLE designs (Samsung's Exynos 8890) had different cacheline sizes on the big and little cores.
glibc's `__clear_cache` would cache the cacheline size on first call, so if the program was started on a big core then migrated onto a little core it would only flush every other cacheline.
And the mitigation was not to "change its allocation", it was to bypass libgcc and handroll cache clearing: https://github.com/mono/mono/pull/3549
Source: https://www.mono-project.com/news/2016/09/12/arm64-icache/
And this issue didn't only affect Mono, it affected pretty much any JIT running on that phone e.g. dolphin (https://github.com/dolphin-emu/dolphin/pull/4204) and ppsspp (https://github.com/hrydgard/ppsspp/pull/8965) had been hitting the same issue and adopted mono's fix, PPSSPP hadn't been able to find the root cause so they'd originally implemented a gnarly hack by adding a bunch of padding (https://github.com/hrydgard/ppsspp/pull/8769).
But fundamentally this is the 8890 being broken: as the Mono post notes, technically nothing precludes core migration in the middle of clearing the cache, which would also lead to broken behaviour, with no mitigation.
-
AppSignal
Monitoring that respects your time & budget. APM, error tracking, and dashboards for modern web apps. Ten-minute setup, transparent flat pricing, and support from engineers who actually use the product.
-
dolphin
Dolphin is a GameCube / Wii emulator, allowing you to play games for these two platforms on PC with improvements.
It was a bit more complicated than that: the issue was that one of the early big.LITTLE designs (Samsung's Exynos 8890) had different cacheline sizes on the big and little cores.
glibc's `__clear_cache` would cache the cacheline size on first call, so if the program was started on a big core then migrated onto a little core it would only flush every other cacheline.
And the mitigation was not to "change its allocation", it was to bypass libgcc and handroll cache clearing: https://github.com/mono/mono/pull/3549
Source: https://www.mono-project.com/news/2016/09/12/arm64-icache/
And this issue didn't only affect Mono, it affected pretty much any JIT running on that phone e.g. dolphin (https://github.com/dolphin-emu/dolphin/pull/4204) and ppsspp (https://github.com/hrydgard/ppsspp/pull/8965) had been hitting the same issue and adopted mono's fix, PPSSPP hadn't been able to find the root cause so they'd originally implemented a gnarly hack by adding a bunch of padding (https://github.com/hrydgard/ppsspp/pull/8769).
But fundamentally this is the 8890 being broken: as the Mono post notes, technically nothing precludes core migration in the middle of clearing the cache, which would also lead to broken behaviour, with no mitigation.
-
ppsspp
A PSP emulator for Android, Windows, Mac, Linux and iOS, written in C++. Want to contribute? Join us on Discord at https://discord.gg/5NJB6dD or just send pull requests / issues.
It was a bit more complicated than that: the issue was that one of the early big.LITTLE designs (Samsung's Exynos 8890) had different cacheline sizes on the big and little cores.
glibc's `__clear_cache` would cache the cacheline size on first call, so if the program was started on a big core then migrated onto a little core it would only flush every other cacheline.
And the mitigation was not to "change its allocation", it was to bypass libgcc and handroll cache clearing: https://github.com/mono/mono/pull/3549
Source: https://www.mono-project.com/news/2016/09/12/arm64-icache/
And this issue didn't only affect Mono, it affected pretty much any JIT running on that phone e.g. dolphin (https://github.com/dolphin-emu/dolphin/pull/4204) and ppsspp (https://github.com/hrydgard/ppsspp/pull/8965) had been hitting the same issue and adopted mono's fix, PPSSPP hadn't been able to find the root cause so they'd originally implemented a gnarly hack by adding a bunch of padding (https://github.com/hrydgard/ppsspp/pull/8769).
But fundamentally this is the 8890 being broken: as the Mono post notes, technically nothing precludes core migration in the middle of clearing the cache, which would also lead to broken behaviour, with no mitigation.
-
> On a single machine I can just replace an `.iter()` into a `.par_iter()` in my Rust programs and boom, I parallelized my workload across every core with only a single line change.
If you’re using Rayon for anything you expect to benefit from a lot of cores, my experiences have been very negative in the past. Rayon is extremely inefficient once you allow it to use more than a handful of cores.[0]
If your unit of work is absolutely massive, you might not be as affected by Rayon’s scheduler, but it makes me sad that this issue still hasn’t been resolved. My comment on that thread was almost 4 years ago! And the issue itself is almost a year older than that.
I no longer consider Rayon to be an advantage for Rust. There are plenty of good ways to wire up a parallel work pool, but they do require more than a one line change.
[0]: https://github.com/rayon-rs/rayon/issues/394
Related posts
-
Unity Game Hacking - Calling FindObjectsOfType in C++
-
How exactly does Unity integrate with IDEs - how does the editor build work?
-
Is there anything inherently wrong with .net applications for self-hosting? (especially in terms of privacy)
-
Mono: A Simple UI/Web/Desktop/Mobile Framework Written in Nim
-
How do I get the target framework assemblies for version 4.6.2 (Or any version) on Linux?