search

git-for-windows / git

A fork of Git containing Windows-specific patches.
http://gitforwindows.org/
Other
8.32k stars 2.53k forks source link

Tracking issue for Windows ARM64 support #3107

Open dennisameling opened 3 years ago

dennisameling commented 3 years ago

There's been a discussion about Windows ARM64 support here: https://github.com/git-for-windows/git/discussions/3021

I made a discussion comment there to keep track of the outstanding tasks to get basic ARM64 support to Git for Windows. However, @Alovchin91 informed me via Twitter that it was hard to keep track of the progress that way, requesting a dedicated issue. So here it is 😊

Open tasks for basic ARM64 support:

Thanks to the changes that we did in the last few days, there's now a fully working build of Git for Windows ARM64.

Test build for ARM64 users, built on March 12, 2021: https://github.com/dennisameling/git/releases/tag/v2.31.0-rc2.windows.2

I think we're pretty much ready to publish a beta version of Git for Windows ARM64! @dscho what do you think? Please let me know if I missed something in the list above.

tommyvct commented 3 years ago

Thanks for point these out. I did realize that the culprit is this environment variable is not set.

@dennisameling Are you using CMake? I may have an idea on how to make it detect arm64.

dennisameling commented 3 years ago

Good news: after having spent some hours with the llvm-mingw toolchain, I was able to build Git for Windows x64 using the llvm-mingw toolchain 🎉 this is incredibly exiting!

PR with super ugly fixes + CI: https://github.com/dennisameling/git/pull/1 The artifacts can be found here: https://github.com/dennisameling/git/actions/runs/1034562965

Things to do:

At this point I'm not sure how much work is still left to get those vcpkg dependencies to build using Clang. Git for Windows maintainers: do you want to wait releasing a Git for Windows ARM64 beta until we have figured out the Clang build or would you be okay with going the Visual C++ route for now (either through static compilation or by installing Visual C++ redistributable in the installer)?

@dennisameling Are you using CMake? I may have an idea on how to make it detect arm64.

@tommyvct Yes, correct. You can check https://github.com/git-for-windows/git/blob/d3c38f5d0bbfa52e23ada776ba74c981dd06bdb1/.github/workflows/main.yml#L160-LL161 to see how we invoke CMake for the ARM64 builds 👍🏼

Alovchin91 commented 3 years ago

Visual C++ is still needed for running the artifacts. I'm pretty sure that's because of the vcpkg dependencies (iconv, expat, etc.) which are built using MSVC.

You're right @dennisameling 🙂 (those are your build artifacts)

dumpbin /dependents C:\Projects\git-llvm\git.exe ``` C:\Windows\System32>dumpbin /dependents C:\Projects\git-llvm\git.exe Microsoft (R) COFF/PE Dumper Version 14.29.30038.1 Copyright (C) Microsoft Corporation. All rights reserved. Dump of file C:\Projects\git-llvm\git.exe File Type: EXECUTABLE IMAGE Image has the following dependencies: zlib1.dll KERNEL32.dll api-ms-win-crt-convert-l1-1-0.dll api-ms-win-crt-heap-l1-1-0.dll api-ms-win-crt-private-l1-1-0.dll api-ms-win-crt-runtime-l1-1-0.dll api-ms-win-crt-stdio-l1-1-0.dll api-ms-win-crt-string-l1-1-0.dll api-ms-win-crt-time-l1-1-0.dll api-ms-win-crt-utility-l1-1-0.dll WS2_32.dll iconv-2.dll api-ms-win-crt-filesystem-l1-1-0.dll ADVAPI32.dll ntdll.dll USER32.dll api-ms-win-crt-locale-l1-1-0.dll api-ms-win-crt-environment-l1-1-0.dll api-ms-win-crt-math-l1-1-0.dll api-ms-win-crt-process-l1-1-0.dll Summary 1000 .buildid 5B000 .data 2000 .debug_abbrev 6000 .debug_info 3000 .debug_line 3000 .debug_loc 1000 .debug_ranges 5000 .debug_str 22000 .pdata A2000 .rdata 4000 .reloc 1000 .rsrc 38F000 .text 1000 .tls ```

But:

dumpbin /dependents C:\Projects\git-llvm\iconv-2.dll ``` C:\Windows\System32>dumpbin /dependents C:\Projects\git-llvm\iconv-2.dll Microsoft (R) COFF/PE Dumper Version 14.29.30038.1 Copyright (C) Microsoft Corporation. All rights reserved. Dump of file C:\Projects\git-llvm\iconv-2.dll File Type: DLL Image has the following dependencies: KERNEL32.dll VCRUNTIME140.dll api-ms-win-crt-runtime-l1-1-0.dll api-ms-win-crt-heap-l1-1-0.dll api-ms-win-crt-utility-l1-1-0.dll api-ms-win-crt-locale-l1-1-0.dll api-ms-win-crt-stdio-l1-1-0.dll api-ms-win-crt-string-l1-1-0.dll Summary 1000 .data 1000 .pdata DF000 .rdata 1000 .reloc 1000 .rsrc 1A000 .text ```
dumpbin /dependents C:\Projects\git-llvm\libexpat.dll ``` C:\Windows\System32>dumpbin /dependents C:\Projects\git-llvm\libexpat.dll Microsoft (R) COFF/PE Dumper Version 14.29.30038.1 Copyright (C) Microsoft Corporation. All rights reserved. Dump of file C:\Projects\git-llvm\libexpat.dll File Type: DLL Image has the following dependencies: KERNEL32.dll VCRUNTIME140.dll api-ms-win-crt-runtime-l1-1-0.dll api-ms-win-crt-stdio-l1-1-0.dll api-ms-win-crt-heap-l1-1-0.dll api-ms-win-crt-utility-l1-1-0.dll api-ms-win-crt-convert-l1-1-0.dll api-ms-win-crt-environment-l1-1-0.dll api-ms-win-crt-math-l1-1-0.dll Summary 1000 .data 2000 .pdata 6000 .rdata 1000 .reloc 1000 .rsrc 1D000 .text ```
mstorsjo commented 3 years ago

But because we have the llvm-mingw toolchain now, it should be possible to also build those dependencies for Windows using Clang instead of vcpkg/MSVC (famous last words). For example, it seems that the MSYS2 team already supports Clang (including ARM64) for mingw-w64-libiconv. What do you think @mstorsjo? What steps would I need to take to build that package using your toolchain? Or more generally speaking, how do I get a working libiconv by building it using Clang instead of MSVC?

So generally I'd say, "just build it the same way you normally do with GCC, but tell it to call the llvm-mingw compilers instead". But if all of that is abstracted away from you, I don't know vcpkg so I could tell you how to run its build scripts while using a separate compiler you provide.

If you're building them using their autoconf configure scripts (in a bash shell), then you just add --host=aarch64-w64-mingw32 to the configure command. But I don't know how vcpkg builds them; if vcpkg uses something like cmake, then you do pretty much the same as you did for git itself.

The same way that you normally build these dependencies for Git for Windows for the x86 builds, that would be GCC based I presume? Just use the same mechanism but slip in --host=aarch64-w64-mingw32 to cross compile them.

At this point I'm not sure how much work is still left to get those vcpkg dependencies to build using Clang. Git for Windows maintainers: do you want to wait releasing a Git for Windows ARM64 beta until we have figured out the Clang build or would you be okay with going the Visual C++ route for now (either through static compilation or by installing Visual C++ redistributable in the installer)?

Wasn't it already concluded that at least static linking of the Visual C++ runtime is possibly problematic wrt GPL? Although maybe it's less of an issue if libiconv and libexpat are LGPL and not plain GPL?

Alovchin91 commented 3 years ago

Git for Windows maintainers: do you want to wait releasing a Git for Windows ARM64 beta until we have figured out the Clang build or would you be okay with going the Visual C++ route for now (either through static compilation or by installing Visual C++ redistributable in the installer)?

I'm not a C++ guy (hence little help from me here, sorry 😞) but I don't think that mixing different runtimes (if you mean building Git with LLVM and those vcpkg-dependencies with MSVC) is a good idea...

tommyvct commented 3 years ago

At this point I'm not sure how much work is still left to get those vcpkg dependencies to build using Clang. Git for Windows maintainers: do you want to wait releasing a Git for Windows ARM64 beta until we have figured out the Clang build or would you be okay with going the Visual C++ route for now (either through static compilation or by installing Visual C++ redistributable in the installer)?

I'm okay with VC++ route, and I would strongly recommend using VC++ afterwards, given that Windows ARM64 LLVM toolchain is still in its infancy. About the possible GPL violation of VC++ route, just download them from Microsoft directly and silently install them would do the trick.

mstorsjo commented 3 years ago

At this point I'm not sure how much work is still left to get those vcpkg dependencies to build using Clang. Git for Windows maintainers: do you want to wait releasing a Git for Windows ARM64 beta until we have figured out the Clang build or would you be okay with going the Visual C++ route for now (either through static compilation or by installing Visual C++ redistributable in the installer)?

I'm okay with VC++ route,

That's an entirely ok decision to make if you prefer that, however...

and I would strongly recommend using VC++ afterwards, given that Windows ARM64 LLVM toolchain is still in its infancy.

What gives you this impression? Sure, as it's not a first party tool but done by someone else than Microsoft, there's always a chance of corner case details not working exactly the same way (and minor details are still fixed every now and then), but it's been fully usable for large scale apps for many years now.

Heck, even in the Build Conference presentation in 2018, when they presented Windows 10 on ARM64 for developers, they showcased VLC - which was built with LLVM, https://youtu.be/vdYIaUeZnqc?t=1338. (Yes the story they tell in the presentation is entirely backwards, they claimed they reached out to us and that it was built with MSVC, but it was indeed built with llvm-mingw, which I had started working on even before MSVC was publicly available targeting ARM64.) Today, LLVM/Clang is used for building major apps like Firefox and Chrome for ARM64. (Sure, they might not be shipping those apps to end users widely, but that's more about support/commitment, not about toolchain stability.)

So "in its infancy" is a mischaracterization here IMO, when it has been working about as long as the platform itself has been publicly available.

Alovchin91 commented 3 years ago

Honestly, I get an impression that if there's any ARM64 compiler still "in its infancy", that'd more likely be MSVC... 🤔

mstorsjo commented 3 years ago

Honestly, I get an impression that if there's any ARM64 compiler still "in its infancy", that'd more likely be MSVC... 🤔

On that topic, here's also a misoptimization I reported in 2019, which they still haven't fixed: https://developercommunity.visualstudio.com/t/Misoptimization-vectorization-for-ARM6/841281 (They had a fix but it broke something else so it had to be backed out, and now they've essentially lost track of the issue and don't seem to be responding any longer.)

tommyvct commented 3 years ago

@mstorsjo I deeply apologize for my ignorance. I'm also sorry that if that sounds like "the whole LLVM is in its infancy", that isn't what I mean.

mstorsjo commented 3 years ago

@mstorsjo I deeply apologize for my ignorance. I'm also sorry that if that sounds like "the whole LLVM is in its infancy", that isn't what I mean.

Ok no worries.

And I understand the concern - the ARM64/Windows target used to be kinda experimental a couple years ago, but at this time it has come a quite long way converging towards being stable and widely used. So at this point, I wouldn't recommend anybody away from trying it. If it turns out it doesn't work, it should be pretty clear (and we'd find a new bug to fix, converging even closer to "stable"), and if it builds correctly, it should be just fine.

Alovchin91 commented 3 years ago

Just to add to this, in the Rust world LLVM is basically the toolchain, and Windows ARM64 toolchain in Rust has been working pretty well for me for quite some time now.

But in any case, from what I've learned following the developments around Windows on ARM, @mstorsjo is the ultimate person when it comes to ARM compilers 😅 If you see anything in MinGW that's ARM or UCRT -- that's basically him 🙃 I think he's the guy to be trusted if he says the toolchain is stable.

dennisameling commented 3 years ago

Update: next to Git itself, I was now also able to build the vcpkg dependencies using the llvm-mingw toolchain (with the exception of OpenSSL). vcpkg already has support for MinGW (through community triplets), but uses the GCC compiler by default. Therefore I did some hacks in https://github.com/microsoft/vcpkg/compare/master...dennisameling:llvm-mingw-clang?expand=1 to use Clang from the llvm-mingw toolchain instead.

vcpkg build progress

✅ zlib ✅ expat ✅ libiconv ❌ openssl ❔ libssh2 ❔ curl

Testing locally

If you want to test this locally, the easiest is to do the following:

Proceeding with OpenSSL

I need some help with OpenSSL. It builds correctly with .\vcpkg install openssl[core]:x64-mingw-dynamic (GCC), but fails with .\vcpkg install openssl[core]:x64-windows-llvm-mingw (Clang).

Here's the build log: openssl-build-log.txt

The MSYS2 team seems to have their own patches for OpenSSL, not sure if that could potentially help: https://github.com/msys2/MINGW-packages/tree/master/mingw-w64-openssl

I have the feeling we're actually very close now - I tested with the generated libiconv on ARM64 and it seems to work without problems 🎉 - can only test properly when we can get all deps to build using the new toolchain.

mstorsjo commented 3 years ago

Proceeding with OpenSSL

I need some help with OpenSSL. It builds correctly with .\vcpkg install openssl[core]:x64-mingw-dynamic (GCC), but fails with .\vcpkg install openssl[core]:x64-windows-llvm-mingw (Clang).

Here's the build log: openssl-build-log.txt

I have the feeling we're actually very close now - I tested with the generated libiconv on ARM64 and it seems to work without problems 🎉 - can only test properly when we can get all deps to build using the new toolchain.

The first error is this:

crypto/aes/aesni-x86.s:7:8: error: unexpected token in argument list
        movl    4(%esp),%eax
                 ^

So it tries to build x86 assembly while building for an aarch64 target - I presume it implies that the target is x86 from the mingw system/target name.

msys2/mingw-packages builds openssl for the clangarm64 target with some local modifications, see https://github.com/msys2/MINGW-packages/commit/54b6558c592ab84fab7affe5934d80062e1bf99f#diff-f5b24df0f7af1ea0ed2e9518521882295e2cfd34b12c0fa7cffcfbd8318c78fc. You'd need to have vcpkg apply such a patch and then make it call the openssl configure with the options mingwarm64 no-asm instead of mingw.

dennisameling commented 3 years ago

You'd need to have vcpkg apply such a patch and then make it call the openssl configure with the options mingwarm64 no-asm instead of mingw.

Thanks for pointing that out! Seems that this logic is set here for vcpkg.

I'm seeing two issues:

mstorsjo commented 3 years ago

You'd need to have vcpkg apply such a patch and then make it call the openssl configure with the options mingwarm64 no-asm instead of mingw.

Thanks for pointing that out! Seems that this logic is set here for vcpkg.

I'm seeing two issues:

It's running into this error:

windres  --target=pe-x86-64  -o libcrypto.res.o libcrypto.rc
make[1]: windres: No such file or directory

You seem to need to have the llvm-mingw toolchain in your $PATH for it to pick that one up, as it doesn't pass an absolute path to it. And it would need to use $ARCH-w64-mingw32-windres and not plain windres. (When running on x86_64, plain windres would output an x86_64 object file, while you need an aarch64 one when cross compiling.)

  • arm64: mingwarm64 no-asm is not available: openssl-arm64-output.txt - looks like the MSYS bundled with vcpkg is 3.1.6-3 (msys2-runtime) while the latest is 3.2.0-8 - maybe that has something to do with it?

What version of msys that is bundled with vcpkg shouldn't really matter - I presume it bundles it only to be able to run some shell script based build systems, but it doesn't use msys' mingw-packages package repo (as the whole point of vcpkg is that it is a package repo of its own, right?).

vcpkg needs to apply a patch on the openssl package, adding support for the mingwarm64 flag; that's what openssl-1.1.1-mingw-arm.patch does in https://github.com/msys2/MINGW-packages/commit/54b6558c592ab84fab7affe5934d80062e1bf99f#diff-311b22777290d9f2334600b22cbe8bd212e5e26d438007b8c2cb15a94206a97c .

mstorsjo commented 3 years ago

vcpkg needs to apply a patch on the openssl package, adding support for the mingwarm64 flag; that's what openssl-1.1.1-mingw-arm.patch does in msys2/MINGW-packages@54b6558#diff-311b22777290d9f2334600b22cbe8bd212e5e26d438007b8c2cb15a94206a97c .

Also, I presume you already had a working built openssl for arm64 using MSVC? In that case vcpkg probably already has some patches on top of openssl to make that configuration work (or just uses some other custom target name like generic or something like that?). It might be easier to just try to make it use whatever target vcpkg uses for msvc/arm64, instead of adding the mingwarm64 target to openssl - but on the other hand, I don't know offhand if there's any important differences between msvc and mingw in there in openssl.

Alovchin91 commented 3 years ago

I think the main implication is that vcpkg uses Visual Studio generator for openssl: https://github.com/microsoft/vcpkg/blob/04658e4cc48b4a52d1e41674198425395a5003c6/ports/openssl/windows/portfile.cmake#L45

mstorsjo commented 3 years ago

I think the main implication is that vcpkg uses Visual Studio generator for openssl: https://github.com/microsoft/vcpkg/blob/04658e4cc48b4a52d1e41674198425395a5003c6/ports/openssl/windows/portfile.cmake#L45

Ah, right, I see

dennisameling commented 3 years ago

vcpkg needs to apply a patch on the openssl package, adding support for the mingwarm64 flag

That worked, thank you! Really appreciate your prompt replies 😊

I think the main implication is that vcpkg uses Visual Studio generator for openssl:

No, there's separate logic for MinGW in the Unix file (just patched it in my branch): https://github.com/dennisameling/vcpkg/blob/27c59233195447e809c49c5889f3de2341a19a55/ports/openssl/unix/CMakeLists.txt#L37L-L50

Also fixed the windres issue in https://github.com/dennisameling/vcpkg/commit/122b4b1a6ffc25747551f3d360b0ffa50b0e8996. I already defined the correct file in https://github.com/dennisameling/vcpkg/blob/5fa5a38a49aaa9956498a954fe2e2a514ffb4782/scripts/toolchains/llvm-mingw.cmake#L32, but apparently it wasn't passed to the OpenSSL compilation process.

All vcpkg packages build successfully now both for x64 and arm64 😍 🎉 https://github.com/dennisameling/git/runs/3086859910?check_suite_focus=true

Now it's time to fix some issues on the Git for Windows-side of things again for ARM64, most notably Cannot determine endianness (that file has some MSVC-specific logic in it, so will need to look into that later)

In file included from D:/a/git/git/contrib/buildsystems/../..\git-compat-util.h:478:
D:/a/git/git/contrib/buildsystems/../../compat/bswap.h:133:4: error: "Cannot determine endianness"
#  error "Cannot determine endianness"
   ^
2 warnings and 1 error generated.
mingw32-make[2]: *** [CMakeFiles\xdiff.dir\build.make:76: CMakeFiles/xdiff.dir/xdiff/xdiffi.c.obj] Error 1
mingw32-make[1]: *** [CMakeFiles\Makefile2:1089: CMakeFiles/xdiff.dir/all] Error 2
mingw32-make[1]: *** Waiting for unfinished jobs....

I'll continue again after the weekend, really need to finish some other things now. Once again, thanks a lot for all the help! Really appreciate it 👍🏼

dennisameling commented 3 years ago

For info: the problem that git --version --build-options returned AMD64 as the CPU instead of ARM64 has been fixed in #3327 (CC @rimrul) 👍🏼

My main goal for this week is to get the ARM64 LLVM/Clang build to work, which is not too far away now. As discussed above in this issue, that'd eliminate the need for including Microsoft Visual C++ Redistributable with Git for Windows ARM64. Will post updates here later this week!

snickler commented 3 years ago

👀👀👀

dennisameling commented 3 years ago

Finally had some time to dive into this further. Was able to successfully create a x64 build of Git for Windows with LLVM/Clang, where both Git and the vcpkg dependencies are built with Clang. So no Visual C++ installation needed 👍🏼 Will look into the arm64 build later.

WIP PR: https://github.com/git-for-windows/git/pull/3427 (also documented the workarounds I used there). CI run: https://github.com/dennisameling/git/runs/3610366055?check_suite_focus=true

ntindle commented 3 years ago

I've been digging into why Azure DevOps doesn't support Windows for Arm and one of the requirements is Git. It looks like there is a bunch of progress being made on git for windows.

https://github.com/microsoft/azure-pipelines-agent/issues/2062#issuecomment-694421675

tommyvct commented 3 years ago

@dennisameling Could you compile a current git version of Git for Windows ARM64? The one on your fork is a little bit old. Thanks!

dennisameling commented 2 years ago

Incredibly excited to announce that I was able to build ARM64 Git for Windows using LLVM/Clang 🚀 The PR is rather hacky and needs quite some finetuning still: https://github.com/git-for-windows/git/pull/3427/

Will provide the binaries here tomorrow 👍🏼

dennisameling commented 2 years ago

Alright - I was able to completely get rid of my hacky vcpkg workaround in #3427 and use the brand-new official MSYS2 clangarm64 packages, like mingw-w64-clang-aarch64-openssl 🚀

Pretty much everything is working now and the PR is almost in a reviewable state. Some unrelated CI issue (which needs to be fixed separately) is blocking me from publishing some Git ARM64 builds here. For the real enthusiasts: you can download some first (working!) ARM64 artifacts from here: https://github.com/dennisameling/git/actions/runs/1378647387

Will provide more updates in the coming days. I can smell the first beta release already!! 🎉

dennisameling commented 2 years ago

Here we go! Test build of Git 2.33.1 for Windows ARM64! The biggest change is that you no longer need Microsoft Visual C++ Redistributable installed, it "just works" as we're using the llvm-mingw Clang compiler now 🎉 Please read the attached release note if you're using Git Bash. Let me know what you think!! 🚀

https://github.com/dennisameling/git/releases/tag/v2.31.1.windows.1-arm64

Alovchin91 commented 2 years ago

Hi everyone,

Since this is moving much slower now, I would like to raise this discussion again:

Shall you maybe consider only supporting Git ARM64 on Windows 11 and use x64 emulation (and ARM64EC for that matter, if possible)?

I've been using Git for Windows under x64 emulation for months and I can say that I've been very satisfied with performance. If you were to release Git for Windows ARM64 with x86 emulated components today, I'd have preferred staying on x64 emulated one.

Given that there is no ARM64 version yet, I believe it could be a great opportunity to make this turn now.

What do you think?

tommyvct commented 2 years ago

ARM64EC is garbage right now. Microsoft have virtually 0 documentation and it is practically unusable on all Autotools and some CMake projects.

Alovchin91 commented 2 years ago

Yeah, it's Microsoft ¯\_(ツ)_/¯ But on a second thought, it doesn't seem like Git would benefit from ARM64EC anyway since I believe it uses cross-process communication.

dscho commented 2 years ago

https://github.com/dennisameling/git/releases/tag/v2.31.1.windows.1-arm64

@dennisameling I finally managed to play with this (a very kind colleague gave me access to their VM). A couple of notes:

hmartinez82 commented 2 years ago

@dscho could this difference be because you're running in a VM? Is the VM emulating ARM64? What are the exact steps you took to test? I can try to repro them in my Surface Pro X

Alovchin91 commented 2 years ago

@dscho If your VM is a Parallels VM on Apple Silicon Mac, then no wonder the (lack of) performance difference 😉

dscho commented 2 years ago

I only know that it's a VM on a Mac Mini.

I can try to repro them in my Surface Pro X

Please do.

What are the exact steps you took to test?

I listed the commands. I cloned git-for-windows/git, then ran time git rev-list HEAD >/dev/null a couple times, then time git log -1000 -p HEAD >/dev/null.

Alovchin91 commented 2 years ago

I only know that it's a VM on a Mac Mini.

If it's an ARM64 VM, then it's an Apple Silicon Mac Mini 🙂 It's tremendously faster than any Windows on Snapdragon device existing today.

Alovchin91 commented 2 years ago

I would also suggest playing with an x64 version of Git for Windows instead of i686. I have a feeling that you'll see that it's actually even faster than current ARM64 with x86 emulated parts.

hmartinez82 commented 2 years ago

My results on my Surface Pro X with Windows 11 32-bit emulated

$ git --version
git version 2.33.1.windows.1

herna@SurfaceProX MINGW32 ~/Downloads/repo (main)
$ time git rev-list HEAD >/dev/null

real    0m2.977s
user    0m0.015s
sys     0m0.031s

herna@SurfaceProX MINGW32 ~/Downloads/repo (main)
$ time git rev-list HEAD >/dev/null

real    0m2.252s
user    0m0.015s
sys     0m0.062s

herna@SurfaceProX MINGW32 ~/Downloads/repo (main)
$ time git rev-list HEAD >/dev/null

real    0m2.279s
user    0m0.015s
sys     0m0.031s

herna@SurfaceProX MINGW32 ~/Downloads/repo (main)
$ time git log -1000 -p HEAD >/dev/null

real    0m2.077s
user    0m0.031s
sys     0m0.031s

64-bit emulated

$ git --version
git version 2.33.1.windows.1

herna@SurfaceProX MINGW64 ~/Downloads/repo (main)
$ time git rev-list HEAD >/dev/null

real    0m2.284s
user    0m0.015s
sys     0m0.015s

herna@SurfaceProX MINGW64 ~/Downloads/repo (main)
$ time git rev-list HEAD >/dev/null

real    0m2.243s
user    0m0.000s
sys     0m0.031s

herna@SurfaceProX MINGW64 ~/Downloads/repo (main)
$ time git rev-list HEAD >/dev/null

real    0m2.209s
user    0m0.000s
sys     0m0.031s

herna@SurfaceProX MINGW64 ~/Downloads/repo (main)
$ time git log -1000 -p HEAD >/dev/null

real    0m2.483s
user    0m0.015s
sys     0m0.015s

ARM-64

$ git --version
git version 2.33.1.GIT

herna@SurfaceProX ARM64 ~/Downloads/repo
$ time git rev-list HEAD >/dev/null

real    0m1.827s
user    0m0.000s
sys     0m0.046s

herna@SurfaceProX ARM64 ~/Downloads/repo
$ time git rev-list HEAD >/dev/null

real    0m1.829s
user    0m0.031s
sys     0m0.031s

herna@SurfaceProX ARM64 ~/Downloads/repo
$ time git rev-list HEAD >/dev/null

real    0m1.836s
user    0m0.000s
sys     0m0.062s

herna@SurfaceProX ARM64 ~/Downloads/repo
$ time git log -1000 -p HEAD >/dev/null

real    0m2.093s
user    0m0.015s
sys     0m0.031s
dscho commented 2 years ago

If it's an ARM64 VM, then it's an Apple Silicon Mac Mini 🙂 It's tremendously faster than any Windows on Snapdragon device existing today.

@Alovchin91 that's funny ;-)

@hmartinez82 Those numbers are really close by (except the first one, which is most likely due to the cold cache effect, so I would not put any stock in it).

hmartinez82 commented 2 years ago

@dennisameling Do you have a newer build by any chance? Or build instructions ? :)

fobrs commented 2 years ago

Any news on an ARM64 build? TortoiseGit for ARM64X is almost ready: See here

dennisameling commented 2 years ago

I'm back with a major update! 🚀

TL;DR - here's a PortableGit version ready for testing: https://github.com/dennisameling/git/releases/tag/v2.37.3.windows.99 (Windows 11+ only)

Background

There were some discussions in this issue last year regarding the VC++ redistributable requirement when building with MSVC. Earlier this year, I managed to get things to build using the llvm-mingw toolchain, but that was suboptimal and undesirable for multiple reasons.

Over the last few months, some major developments happened:

So basically, we're in great shape now to move forward with the ARM64 support!

Current progress

Here's a bunch of MRs to get a native PortableGit for clangarm64. First version can be downloaded for testing here, and I've listed some known issues in the release description.

More information & discussion topics

For an overview of all the environments that MSYS2 currently support and how they differ, see this page.

While a lot more stuff is native ARM64 now (see below), it's good to know that all unixy tools in /usr/**/* like Bash currently use x64 emulation (this is a known issue in MSYS2). I'm not seeing this change any time soon, as they rely on Cygwin adding ARM64 support too. Since those tools are x64 only, it means that Git for Windows ARM64 would only work on Windows 11+, as Windows 10 ARM64 only supports x86 emulation.

I know that there's a small subset of ARM64 users that can't upgrade to Windows 11 due to unsupported processors like the Snapdragon 835 (which is stuck on Windows 10 1803 actually). Generally speaking, I'm in favor of requiring Windows 11+ as it will be very hard (if not impossible) for the Git for Windows maintainers to use the git-sdk-32 for building ARM64. That SDK relies on MSYS2 and Cygwin x86. MSYS2 already dropped x86 support back in 2020 and Cygwin has already released their final version (3.3) that supports x86.

|- bin/* (native ARM64)
|- clangarm64/**/* (native ARM64)
|- usr/**/* (x64 due to MSYS2 being x64-only: https://www.msys2.org/wiki/arm64/)
mattwojo commented 2 years ago

ARM64EC is garbage right now. Microsoft have virtually 0 documentation and it is practically unusable on all Autotools and some CMake projects.

Just seeing this and notice that it's from back in January, but in any case, we've got ARM64EC docs now: https://learn.microsoft.com/windows/arm/arm64ec Hope they're helpful - please file an issue if you see any issues.

fobrs commented 2 years ago

ARM64EC is garbage right now. Microsoft have virtually 0 documentation and it is practically unusable on all Autotools and some CMake projects.

Just seeing this and notice that it's from back in January, but in any case, we've got ARM64EC docs now: https://learn.microsoft.com/windows/arm/arm64ec Hope they're helpful - please file an issue if you see any issues.

ARM64EC is not needed IMHO by Git for Windows ARM64

mattwojo commented 2 years ago

ARM64EC is garbage right now. Microsoft have virtually 0 documentation and it is practically unusable on all Autotools and some CMake projects.

Just seeing this and notice that it's from back in January, but in any case, we've got ARM64EC docs now: https://learn.microsoft.com/windows/arm/arm64ec Hope they're helpful - please file an issue if you see any issues.

ARM64EC is not needed IMHO by Git for Windows ARM64

Windows 11 will automatically emulate x64 code, but ARM64EC enables optimizing code to run faster/more efficiently on Arm devices by allowing x86 and ARM64EC code to be mixed so you can update an app incrementally, focusing on the highest impact improvements. ....but all this is diverging from the actual issue here. (Apologies!)

Alovchin91 commented 2 years ago

Just wanted to share.

We're using Git for Windows as a workaround for LibGit2's network performance issues. We also now have many customers who use our software in Parallels on M1 Macs. Unfortunately, because Git for Windows is x64 emulated, it seems to cancel out all the performance gains from using it over LibGit2 (which is compiled natively for Arm64).

So from my perspective, I don't really care if it's Arm64 or Arm64EC; I would be happy to have either.

Alovchin91 commented 2 years ago

I also wonder what happened to Microsoft's promise to help with it. I suppose they also need it for Visual Studio Arm64.

dennisameling commented 2 years ago

@dscho is actually steadily working on reviewing the PRs I linked here, so keep an eye on those for more updates 😄 This is the most important one which will unblock further work on all the different builds (portable, mingit, installer, etc.).

fobrs commented 2 years ago

ARM64EC is garbage right now. Microsoft have virtually 0 documentation and it is practically unusable on all Autotools and some CMake projects.

Just seeing this and notice that it's from back in January, but in any case, we've got ARM64EC docs now: https://learn.microsoft.com/windows/arm/arm64ec Hope they're helpful - please file an issue if you see any issues.

ARM64EC is not needed IMHO by Git for Windows ARM64

Windows 11 will automatically emulate x64 code, but ARM64EC enables optimizing code to run faster/more efficiently on Arm devices by allowing x86 and ARM64EC code to be mixed so you can update an app incrementally, focusing on the highest impact improvements. ....but all this is diverging from the actual issue here. (Apologies!)

To get it straight. On Windows ARM64 x86 code is emulated, including all used x86 (system) DLL's. Under Windows 11 ARM64 x64 code is emulated. But if it uses a DLL, the OS looks if the DLL is ARM64X. That is, it has both ARM64 and ARM64EC (x64) calling conventions code. If ARM64EC code is present in the DLL it uses that code. So emulated x64 code can use ARM64EC code in ARM64X DLL's. That means all system DLL's under Windows 11 ARM64 are larger in size as the ARM64EC code needs to be in there too. The ARM64 version of TortoiseGIT has a x86 shell extension DLL and an ARM64X extension DLL. So, every case is covered.

Alovchin91 commented 2 years ago

On Windows ARM64 x86 code is emulated, including all used x86 (system) DLL's.

A tiny correction: x86 system DLLs are actually CHPE, so they should run at almost native speed. Not all of them though.