Support Board
Date/Time: Sat, 23 Nov 2024 17:17:45 +0000
[User Discussion] - Performance on Apple Silicon vs x86 VM
View Count: 1585
[2024-05-05 11:07:40] |
MichaelPPTF - Posts: 69 |
I've done some tests on running Sierra with Apple Silicon Macs and x86 Virtual Machine. It turns out when running on M1 Mac Mini with 16GB RAM using Whiskey (A free WINE Wrapper), it achieved near native performance vs running in an x86 VM with 16GB of RAM, too. 1) Mac Mini M1, 16+512, using Parallels to virtualize a Windows 11 Pro VM, running SierraChart_arm64.exe Exporting bar data to a file took 3.6 seconds (!!!!) 2) Mac Mini M1, 16+512, using Whiskey translation layer running in MacOS, running SierraChart_64.exe (arm64 won't run for some reason) Exporting bar data took 250 milliseconds 3) x86 VM, i5 12th gen, 16G RAM + 128G vDisk on SSD, running SierraChart_64.exe Exporting bar data took 234ms. All these installations are identical. I zipped the main install from the x86 VM and extracted all the files in other platforms. An update was done prior to packing the files. I would think if SierraChart_arm64 could run in MacOS the performance would be even better. But near native performance even when running the x86 executable was a nice surprise. Update 5/10/2024: I feel the need to clarify some things. Apple Silicon is based on ARM architecture, and its compatibility with x86_64 (Intel) applications is facilitated by Rosetta 2, a translation technology. Rather than directly executing x86_64 code, Apple Silicon uses Rosetta 2 to dynamically translate x86_64 instructions into ARM instructions at runtime, enabling compatibility with x86_64 apps. In the past, when Apple used Intel x86 CPUs, running Windows programs on a Mac involved translating x86 Windows API calls to MacOS equivalents. This could be done through emulation or by setting up a virtual machine running x86 Windows. However, with the transition to Apple Silicon, the process has become more complex. Running x86_64 Windows programs on Apple Silicon Macs now requires additional layers of translation. Solutions like Parallels and UTM provide virtual machines that run ARM-based Windows, which then use Microsoft's x86 emulation layer on ARM to run x86_64 Windows applications. This means there are two layers of translation involved: MacOS -> QEMU virtual machine (running ARM-based Windows) -> x86_64 Windows -> ARM translation layer. On the other hand, solutions like WINE, Whiskey, and CrossOver do not involve emulation. These programs translate Windows API calls directly into MacOS API calls. While this approach avoids the performance overhead of emulation, it doesn't guarantee full compatibility, as translating API calls between different platforms and architectures can be complex. Apple values backward compatibility, which is why efforts have been made to make ARM MacOS API calls as similar as possible to x86_64 ones - if they don't, then Rosetta 2 comes to the rescue. This similarity enables x86_64 Windows programs to be translated to run on ARM-based MacOS without the need for an additional layer of emulation. As a result, programs generally perform better when using WINE-based solutions. For the compatibility reason, I am still not fully onboard with running Sierra with ARM MacOS. For example, WINE does not run Sierra_arm64, because it doesn't know how to translate ARM Windows API calls for MacOS. It is easy to understand because even Microsoft themselves need a translation layer to run x86 Windows programs on ARM Windows. So, it looks like running Arm-native Sierra on MacOS while having good performance is still very far away. I believe two things need to happen: Sierra releases an ARM-native Linux build, and a Linux distro that supports graphical acceleration when virtualized in MacOS. Date Time Of Last Edit: 2024-05-10 17:22:50
|
write_bar_study_arm_win_vm_parallels.png / V - Attached On 2024-05-05 11:00:04 UTC - Size: 42.74 KB - 117 views write_bar_study_arm_win_whiskey.png / V - Attached On 2024-05-05 11:00:09 UTC - Size: 13.04 KB - 109 views write_bar_study_x86_win_vm.png / V - Attached On 2024-05-05 11:00:13 UTC - Size: 38.23 KB - 107 views |
[2024-05-08 17:04:44] |
gtaranti - Posts: 67 |
Hey, what do you mean 'x86 Virtual Machine'? What was the host? If'd like to share some details here... I'm also running a copy of Sierra Chart in Parallels (Mac Mini M1, 16Gb) and I'd like to know if there is another faster way of running it. |
[2024-05-08 17:23:54] |
MichaelPPTF - Posts: 69 |
x86 Virtual Machine means a virtual machine that runs on x86 platform. In my case that was an Intel 12th gen Core i5 Processor. If you want good performance, run Sierra with Whiskey in MacOS. Parallels is bad. |
[2024-05-08 17:25:34] |
gtaranti - Posts: 67 |
Thanks, I'll try it.
|
[2024-05-09 01:46:06] |
ivory - Posts: 95 |
Performance is important, but it only matters when things work correctly. I don't care about things that are fast, but give incorrect results. So the question is... can you chart and trade reliably with whisky? I have Crossover for Mac - Sierra running under it is much faster than under Parallels and integrates into the windowing system much better. So what? Every time i tried it, I would find that features I rely on are broken. |
[2024-05-10 00:45:17] |
ivory - Posts: 95 |
To answer my own question, Whiskey seems to work much better than Parallels and, more importantly, CrossOver. I am a bit surprised about the latter, since it's supposed to be a better supported version of wine, but it is what it is. I've been running my regular charts with Whiskey for one day, placed some sim and real trades (small size just to be sure) and it worked very well. No issues of any kind noted yet. This is really heartwarming. Thank you Michael for bringing this to my attention. I've spent months trying to replace Sierra with other software that runs without a VM on the Mac and it was just an exercise in plowing a field with bare hands. This is such a relief. I just hope it won't break tomorrow :) Date Time Of Last Edit: 2024-05-10 00:47:39
|
[2024-05-10 07:11:47] |
gtaranti - Posts: 67 |
For me it's Parallels and SierraChart_ARM64.exe for now. It's running significantly faster than the x64 version (SierraChart_64.exe). I know I said I'll try Whisky but the thing is that I need to build my custom ARM64 study (in order to use in the ARM version of SC) and I don't know if this is even possible in the Whisky environment. |
[2024-05-10 13:42:28] |
ivory - Posts: 95 |
gtaranti everything I wrote was about SierraChart_64.exe. Thanks for the heads up about the ARM64 version. Will check if Whiskey can run it and let you know how it goes.
|
[2024-05-10 13:46:39] |
MichaelPPTF - Posts: 69 |
Will check if Whiskey can run it and let you know how it goes.
No. Whiskey will only run the normal version, not the ARM64 version. |
[2024-05-11 01:09:09] |
ivory - Posts: 95 |
Running SierraChart under Whiskey and Spotify at the same time is the only way I know to make my M1 Max so hot, that fans start spinning at full speed. I forgot what they sound like, because I haven't heard them in well over 2 years. I find it interesting, that even simulating an entire computer with Parallels, running a second OS, and Sierra in it doesn't have that effect. Not sure what it is, could be the way wine server works. Spotify has always made the computer warm, but nothing was able to push it over the edge the way SC + Whiskey does. That is not to say the solution is not good. It's vastly more comfortable to use than Parallels due to better integration with MacOS's windowing system. It is noticeably faster, too. I did not encounter any bugs to date. I suppose it will become a balancing act of what to use and when to use it to keep things running reasonably well. |
[2024-05-11 01:13:52] |
ivory - Posts: 95 |
and a Linux distro that supports graphical acceleration when virtualized in MacOS.
If running Linux directly is of interest, then that already exists and is called Asahi Linux. Their drivers are OpenGL 4.6 and OpenGL ES 3.2 compliant. However, at this time, they are lacking external display support other than experimental HDMI display driver for the few models that have that socket. https://social.treehouse.systems/@AsahiLinux |
[2024-05-11 02:45:25] |
MichaelPPTF - Posts: 69 |
make my M1 Max so hot
I am curious how did that happen. Granted I didn't load my Sierra with 20 studies per chart but I never had the issue. And Spotify was heating up the machine? That's odd. running Linux directly is of interest
Nah, abandoning MacOS and use Linux(desktop) is self-abuse. Actually, for $150 or so, one can get a mini PC that runs Sierra very well. Pair it with low latency RDP software like Parsec, the experience is way better than running Sierra locally with Parallels/UTM and don't have to worry about compatibility issues. Of course, running it with WINE is still a better option usability wise with native window management and stuff. |
[2024-05-11 03:01:02] |
ivory - Posts: 95 |
I am curious how did that happen. Granted I didn't load my Sierra with 20 studies per chart but I never had the issue. And Spotify was heating up the machine? That's odd.
Since I've got the Spotify app it'd always make the computer warm, but not enough to make fans spin. Interestingly enough, if I use Spotify through the web browser, it's perfectly fine. Something about their "app" that makes that happen. I'm using the 16" 2021 M1 Max model. I was experimenting with Sierra on Whiskey today. I wanted to run two instances - one for longer term charts and one with very short term charts. The former would load more data, but the refresh rate for all charts would be very low. The latter would load minimum amount of data (1-5 days depending on the chart), but have higher refresh rates. I don't use many studies. On most charts I have 2 instances of ECIVwap each and cumulative volume delta. On some I have numbers bars instead of CVD. It seems that it was running two programs with Whiskey that pushed it over the edge. I have now reverted to a standard setup, where all my charts are on one instance. The "Energy Impact" number for Whiskey, from the Activity Monitor, has halved after that, hence my earlier comment that it probably has something to do with how wine server works. Actually, for $150 or so, one can get a mini PC that runs Sierra very well. Pair it with low latency RDP software like Parsec, the experience is way better than running Sierra locally with Parallels/UTM and don't have to worry about compatibility issues. Of course, running it with WINE is still a better option usability wise with native window management and stuff.
Remember people use laptops for a reason. I travel a lot. Every kg and cm of equipment comes at a heavy premium. If I was home based, I'd just buy myself a Windows PC and forget about all those MacOS-vs-Sierra troubles. |
[2024-05-11 19:32:06] |
MichaelPPTF - Posts: 69 |
I travel a lot
It's RDP, you don't need to carry the thing around. It sits in your primary residence with Internet connection then you can just remote to it whenever you feel like to. |
[2024-05-11 19:51:53] |
ivory - Posts: 95 |
It sits in your primary residence with Internet connection then you can just remote to it whenever you feel like to.
I don't see the benefit over colocated remote desktop services. One way or the other, I prefer to run software natively whenever possible. |
[2024-05-13 01:41:20] |
MichaelPPTF - Posts: 69 |
I prefer to run software natively whenever possible.
Yep, it runs on x86 natively, not on ARM. |
[2024-05-26 07:27:02] |
ivory - Posts: 95 |
I've been running Sierra with Whisky for almost 2 weeks now. I have to say this is the best experience I've had with SierraChart on macOS to date. There are only three issues that I noticed so far: 1. Ctrl and Option keys act weirdly. I remapped all my keyboard shortcuts to avoid them. Sometimes Wine thinks Ctrl remains pressed when I switch between programs. I just have to press ctrl again after Sierra window is in focus again to solve the problem. I've experienced this problem before when using wine without Whisky and with Crossover 2. The heating up problem sometimes shows up, but I found this really weird solution... turns out, that the culprit is not SC running under Wine/Whisky, but a combination of Sierra and Whisky app/bottle management panel. If I close Whisky (the program that allows you to see all the bottles), the energy usage drops by more than half and the computer cools down very quickly. If I have the panel open, but Sierra is closed, the problem does not occur either. 3. The message log is spammed with 2024-05-26 00:00:09.156 | File compression not supported on file system. C:\SierraChart\Data\CLV3.NYMEX.dly. Windows error code 50: Request not supported. This issue has been discussed at length in Linux thread. Not sure if there's anything that can be done with it on macOS. No impact on me other than spamming the Message LogI had Sierra crash once when I was resizing a window. Overall, it seems that the biggest challenge to wine is drawing. I haven't experimented with turning OpenGL on and off yet, will see if it helps or not. |
[2024-05-26 11:42:16] |
ivory - Posts: 95 |
I haven't experimented with turning OpenGL on and off yet, will see if it helps or not.
Well, that was a very short test. Selecting the OpenGL option is not possible. With each restart, it just gets unchecked for some reason. |
[2024-08-03 20:39:15] |
JohnGrasty - Posts: 18 |
I just wanted to confirm the below from Ivory's post. Closing the Whiskey app after launching SC made a significant difference is lowering CPU usage. Thanks so much for posting that! 2. The heating up problem sometimes shows up, but I found this really weird solution... turns out, that the culprit is not SC running under Wine/Whisky, but a combination of Sierra and Whisky app/bottle management panel. If I close Whisky (the program that allows you to see all the bottles), the energy usage drops by more than half and the computer cools down very quickly. If I have the panel open, but Sierra is closed, the problem does not occur either.
|
[2024-08-03 21:42:48] |
seandunaway - Posts: 268 |
i have a different experience after extensive testing. i've been running sierra from mac for years and from arm since m1 i find wine's (devel and crossover) performance unacceptable and specifically wine's networking stack seems broken with sierra on macos. the newer linux compatibility setting doesn't help. wine does not support arm64 binaries and every wine instance is rosetta2'd windows 11 also has it's own x64 to arm64 binary translation like rosetta2, so it can run both. the translated executable must be one-time cached because i can't tell any performance differences. i do however prefer to run the arm64 binaries sierrachart arm64 on windows 11 iot arm64 via parallels is an absolute pleasure. i like that it's running native without the wine setsockopt or file compression errors. it is somehow more performant than my last xps 17 and allows me to run on battery literally four times as long. make sure you enable opengl i wrote a little bit more about it here: Sierra Chart Executables for ARM 64 Processor @gtaranti, you might like: cross compile from macos targeting both aarch64 and x86_64 @michaelpptf, will you please verify you're not trying to write to file across a network or virtualization boundary? it's better to write into the guest filesystem i haven't tried whisky yet, are they using a variant of wine that is improved over crossover or the development branch? Date Time Of Last Edit: 2024-08-03 22:35:47
|
[2024-08-06 14:00:22] |
JohnGrasty - Posts: 18 |
Well, guys, I've jinxed us. 😁 I have significant UI issues with Whiskey and SC now in 2665 and 2666 builds. 🙁 Essentially, dialog windows are acting very strange and not accepting inputs or basically freezing. Anyone else with Whiskey and recent builds running into this? (And SC engineering, I realize that this is not your problem, and this is very much an unsupported use case. 😁) |
[2024-08-06 14:09:21] |
MichaelPPTF - Posts: 69 |
@michaelpptf, will you please verify you're not trying to write to file across a network or virtualization boundary? it's better to write into the guest filesystem
I can't say for sure. I've used default settings for Parallels, which allocated what I think should be enough for SC (CPU, GPU, RAM, VM Disk, etc). But based on my understanding, I did not write files to a network share, everything was contained in the VM Disk. @JohnGrasty - I have my SC version at 2634, it seemed to work the best. However, the message log was spammed with error messages related to data file compression, and I can't see my trade records, which is inconvenient. |
[2024-08-06 14:24:46] |
Sierra_Chart Engineering - Posts: 17150 |
@JohnGrasty - I have my SC version at 2634, it seemed to work the best. However, the message log was spammed with error messages related to data file compression, and I can't see my trade records, which is inconvenient. Advanced Service Settings: Support Intraday and Market Depth Files Compression (Global Settings >> Advanced Service Settings >> Other) And we definitely recommend updating Sierra Chart. We do not know why a particular version would seem to work the best. They are generally all the same. Newer versions always have improvements and issues resolved, and small performance improvements. Sierra Chart Support - Engineering Level Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy: https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation For the most reliable, advanced, and zero cost futures order routing, use the Teton service: Sierra Chart Teton Futures Order Routing |
[2024-08-06 15:32:45] |
seandunaway - Posts: 268 |
2 minute 40 second video attached showcasing the networking issues i have with wine and downloads that are 10x slower than native on macos which really makes a difference with tick data
|
sierrachart wine networking macos.mp4 - Attached On 2024-08-06 15:32:34 UTC - Size: 60.22 MB - 135 views |
To post a message in this thread, you need to log in with your Sierra Chart account: