tdesktop
tdesktop copied to clipboard
telegramdesktop
[Feature Request] Build Telegram for ARM64EC target for Windows 64-bit
Is your feature request related to a problem?
Telegram runs under x64 emulation on Windows ARM devices, that causes a performance penalty especially with the CPU intensive tasks like video/GIFs, etc.
Creating a new ARM64 build might be costly, but Windows applications can be compiled for ARM64EC target which is essentially x64 but with ability to directly translate to ARM so it can be transpiled to the native code on ARM platforms.
Here are the details: https://devblogs.microsoft.com/cppblog/arm64ec-support-in-visual-studio/
Describe the solution you'd like
ARM64EC enabled x64 binaries for Telegram.
Describe alternatives you've considered
I considered suffering through performance problems, I didn't like it.
Additional context
No response
Telegram cannot be ported to ARM64 just yet because some third-party dependencies are not ready (e.g. Qt ARM64 builds are still in tech preview). But ARM64EC might be a good compromise for now: Telegram runs natively and everything else stays x64.
~Also porting can be done iteratively: replace the x64 dependencies with ARM64 builds step by step. Once all third-party dependencies are updated, just change the build target from ARM64EC to ARM64.~
Edit: Forget the last part. The Microsoft docs state that ARM64EC can load x64 and ARM64EC binaries but they cannot load ARM64 binaries.
Telegram cannot be ported to ARM64 just yet because some third-party dependencies are not ready (e.g. Qt ARM64 builds are still in tech preview). But ARM64EC might be a good compromise for now: Telegram runs natively and everything else stays x64.
~Also porting can be done iteratively: replace the x64 dependencies with ARM64 builds step by step. Once all third-party dependencies are updated, just change the build target from ARM64EC to ARM64.~
Edit: Forget the last part. The Microsoft docs state that ARM64EC can load x64 and ARM64EC binaries but they cannot load ARM64 binaries.
Hey Team,
My name is Nicolas Ochoa, and I am an App Assure Manager with Microsoft's FastTrack Center. My team assists Microsoft customers and Independent Software Vendors (ISVs) with any application or software compatibility scenarios encountered while upgrading to our latest versions of Microsoft products.
We would like to work with Telegram to prepare your applications for Windows on Arm.
The App Assure team supports application compatibility for Windows 10, Windows 11, and Windows on Arm with an emphasis on collaborating with ISVs. Our goal is to help ensure your Telegram application is supported on Windows 11 and Windows on Arm. Our App Assure engineers can provide you with best practice guidelines and help remove any technical blockers encountered when developing compatible applications. These services are provided at no additional cost.
Feel free to reach out to me by replying to this thread
Arm64EC supports ARM64 code, but not ARM64 binaries. It works very well for partial ports in conjunction with a good linking strategy (the arm64 codebase in ARM64 and Arm64EC can be the same code essentially and ultimately you can produce Arm64X if needed to support both types from a single binary should you have any dlls which need to be able to load in both types of processes). Arm64EC is usually where I'd suggest open source projects with lots of dependencies start looking; you can get pretty great performance without having to recompile everything into Arm64.
Arm64EC supports ARM64 code, but not ARM64 binaries
Is that a blocker for Telegram Desktop?
Telegram cannot be ported to ARM64 just yet because some third-party dependencies are not ready (e.g. Qt ARM64 builds are still in tech preview). But ARM64EC might be a good compromise for now: Telegram runs natively and everything else stays x64.
There was a need to patch few qmake files but nothing significant and overall the Qt builds for windows arm64 and works without any issues. Both with LLVM-Mingw64 and MSVC, the full source tree including the IDE, no problem at all. Though I checked it more than two years ago, I believe they didn't break it so far.
P.S. For an open source project, when the dependency sources are available, depending on the prebuilt libraries seems quite weird for me. Aren't you guys supposed to have at least some good and healthy paranoia when it comes to dealing with the 3rd the party blobs?
@CryptoManiac Currently the Qt arm64 builds are considered stable but the tooling isn't there yet. See https://www.qt.io/blog/qt-for-windows-on-arm
Qt basically works natively on Windows on ARM. It is usable to build and run native Qt applications for your ARM64 devices but you will have to build Qt yourself. We, the Qt Company, still have some work to do to make the developer experience come up to par with the rest of our offering though.
There are no official binaries yet and I don't think this project wants to built Qt itself.
Well, really this project (if you're talking about TDesktop) builds (and patches) Qt itself on all platforms for ten years now. But I'm not sure about ARM build of all other dependencies, Qt is just one, on Windows there are 28 steps in dependencies-building script. Right now I don't have time to check/port building all of them to ARM and then building one more version for each release :(
But I'm not sure about ARM build of all other dependencies
I mean, that is the point of ARM64EC: use this target for the core of TDesktop and the (third-party) dependencies can stay x86-64. Then migrate the rest iteratively one step at a time.
Right now I don't have time to check/port building all of them to ARM and then building one more version for each release :(
I would help out if I had any C++ building experience. I'm still hoping someone else will be interested in giving it a shot. 😅
In light of all the new windows ARM hardware released with the snapdragon chips, I would love to see a native version of telegram.
i am sure windows arm users is far lower than linux arm users wicth is far lower than linux x86 users and preston have far higher priorities, when windows arm can run windows x86_64 binaries.
As an active Windows ARM + Telegram user, I prefer the web version because ARM experience of Telegram in WIndows is awful:
- The UI elements are painfully slow. While app and calling technically does work, pressing every button is about a 5-second delay. And you have to press 3 buttons to make a call
- It requires 500+ MB of RAM to just sit there while web version is less than 300. Calling on web version of telegram does not work on Edge/ARM. I believe x86 version of telegram is less than 100MB
- Launching telegram is also about a 5-sec delay and depends on luck
On the overall Windows/ARM projections I believe this will get a lot of traction because it works at least as stable as x86 with more than acceptable performance and provides unbeatable benefits in battery, 5G connectivity, temperature and noise
i am sure windows arm users is far lower than linux arm users wicth is far lower than linux x86 users and preston have far higher priorities, when windows arm can run windows x86_64 binaries.
@Aokromes, What's the minimum number of people affected to address an issue?
While the native WoA build is unavailable, you could use Android version. It works fine with Windows Subsystem for Android. It's an ugly crutch of course, but Android version is far more usable than Windows x86_64 version. If anything, you'll be able to make calls without spending five minutes on establishing the connection. Hope it helps. An alternative is to use Linux version with WSLg.
i am sure windows arm users is far lower than linux arm users wicth is far lower than linux x86 users and preston have far higher priorities, when windows arm can run windows x86_64 binaries.
It works fine as long as you won't try to make a voice or video call. Something is severely broken in the cryptographic keys negotiation code. Broken so much that I have enough time to make a tea before the connection will be established. Win 11 on Qualcomm Snapdragon 8cx Gen 3 with 16 Gb of RAM. It looks like this particular code is dependent on the instruction(s) which are very hard to emulate, resulting with the ridiculously high emulation penalties. I guess this can be worked around by invoking the unoptimized code for this particular use case but this will require modifications. The application will need to be able to detect that it's running under the emulation and use the plain C version of that function in such a case, then it will be somewhat tolerable.
It works fine as long as you won't try to make a voice or video call.
Nope, autoplay GIFs and videos are problematic too. Telegram is still the top battery consumer on my Surface Laptop 7 without making a voice or video call.
It works fine as long as you won't try to make a voice or video call.
Nope, autoplay GIFs and videos are problematic too. Telegram is still the top battery consumer on my Surface Laptop 7 without making a voice or video call.
Didn't notice any trouble with them. Works fine for me. Battery consumption is another matter, though.
Didn't notice any trouble with them.
Yeah, GIFs and videos play smooth, but they consume a lot of power due to emulation running behind the scenes. That's what I meant as problematic.
I have a Samsung Galaxy Book S (Snapdragon 8cx) and can't confirm any of the mentioned performance issues. Are you sure that you are running the x64 build (NOT x86)?
The battery usage is very poor though judging by the Windows logs.
@ssg Well, from Unigram statistics the ratio of x64 users to arm users is 16'945, meaning there is almost 17'000 people using x64 version on every person using arm version, or arm userbase is ~0.006%
Given that I've EOLed support for systems under 1% of userbase when the time came it's really hard to justify spending big amount of time (working week? idk) to support native arm version for 0.006% of userbase.
BTW for me this percent would be even less, because Unigram works only on modern systems, while I still have relatively big percent of users on Windows 7 (more than 4% of userbase).
idk.. I'm open for the thing, but it is really hard to make (and support, and build every release) a native arm version and really low part of userbase
@john-preston You would have to copy the Windows x64 pipeline, change the build target to Arm64EC and leave everything else (like x64 dependencies) as is. So that's 1-2 days max? But without proper hardware or VMs there is just no way to test it yourself.
Maybe Microsoft (@NicolasOchoaMSFT) would be willing to send you a Windows Dev Kit 2023? 😄
@sungaila I'm not sure building tdesktop code Arm native and leaving dependencies x64 (like OpenSSL / FFmpeg / WebRTC) will do any good in terms of performance, I doubt that tdesktop code is the main problem here. It looks like a fully native build is needed for all this to make sense.
I hope I'll be able to use Mac hardware for Windows on Arm development, that way I still need only two hardware sets to build all of supported tdesktop versions (Mac on Apple Silicon builds both x64 and Arm macOS versions, Windows on x64 builds Windows x86, Windows x64 and Linux x64 versions).
@john-preston You would have to copy the Windows x64 pipeline, change the build target to Arm64EC and leave everything else (like x64 dependencies) as is. So that's 1-2 days max? But without proper hardware or VMs there is just no way to test it yourself.
Maybe Microsoft (@NicolasOchoaMSFT) would be willing to send you a Windows Dev Kit 2023? 😄
Raspberry Pi will do. There is no need for expensive hardware to run these binaries. It's painfully slow however. One might even say that forcing someone to use windows on Raspberry Pi should be classified as a war crime.
I don't want another distinct hardware, I really do hope Apple Silicon would do. I already need it for macOS builds.
@john-preston You could be right, I too doubt that tdesktop is the bottleneck here.
For development you can run Windows 11 on ARM via virtualization on your Mac (e.g. https://kb.parallels.com/en/125375).
Windows cross-compiles to x86, x64, arm64 and arm64ec on each platform. You'd need Windows on ARM to test the binaries but not for compiling.
@john-preston You could be right, I too doubt that tdesktop is the bottleneck here.
For development you can run Windows 11 on ARM via virtualization on your Mac (e.g. https://kb.parallels.com/en/125375).
Windows cross-compiles to x86, x64, arm64 and arm64ec on each platform. You'd need Windows on ARM to test the binaries but not for compiling.
UTM is open source and works reasonably well. There is no GPU acceleration on Windows guests, however, but it's still more than enough for testing and development.
https://mac.getutm.app
I have Windows on Arm in Parallels Studio there. I just didn't manage to go further than first dependency out of 28 that I need to compile in order to build tdesktop on Arm 😢
The cross-compiling also sucks for tdesktop because there are several code generator built and used (!) before tdesktop itself, so the resulting process is very complicated if you try to cross-compile. You need to build some libraries and codegens in host arch, then make them (the resulting binaries) available for cmake configuration run for target arch and build all those libraries and everything after the codegens run on target arch.
Apple did a really good job with their approach to two archs and universal binaries + cmake supported it, so on Apple you almost don't think about archs at all, you build all dependencies for both archs and join them in universal binary libraries (the same way on any arch you build, on Intel or Apple Silicon, you build them the same way) and then you build half of your targets (libraries and codegens) for both archs the same way on both hardware setups, and all target-arch-only libraries and tdesktop itself could be built either for both archs into universal binaries (if you need to deploy) or for a single arch only (if you need to debug and test, then you build only your host arch) -- and again, you do it the same way on any hardware, Intel or Apple Silicon. And cmake helps you all the way, giving you a way to configure wanted archs on per-target basis.
I think if Microsoft could've done something similar that would really improve the adoption of Windows on Arm for developers. I understand that's really hard thing to do so that it all works smoothly. But here we are. Another pain on Windows for that task is that some dependencies (current libvpx and ffmpeg) have no way to be built natively in development command prompt and rely on msys2 to be built for Windows, which adds complexity to building for different archs.
I have Windows on Arm in Parallels Studio there. I just didn't manage to go further than first dependency out of 28 that I need to compile in order to build tdesktop on Arm 😢
I've gave up on 11th or thirteen, don't remember exactly. Stumbled upon x86 inline assembly somewhere and decided to act like that exorcist priest from a movie. Some WebRTC library if I remember correctly.
Thanks for the in-depth explanation, it makes it clearer which hurdles have to be overcome. Thankfully the x64 emulation is good enough imho.