Skip to content

build node.js using clangcl when under Windows #52809

Closed
Closed
build node.js using clangcl when under Windows#52809
Labels
buildIssues and PRs related to Node.js builds or CI infrastructure.windowsIssues and PRs related to the Windows platform.

Description

@lemire
lemire
opened on May 2, 2024

Description

Chrome and Firefox are built with Clang under Windows.

@targos made it possible to build Node.js using clang under Windows, see #35433

At least in some tests, this seems to result in better performance:

                                                          confidence improvement accuracy (*)    (**)    (***)
v8\get-stats.js n=1000000 method='getHeapSpaceStatistics'                 3.36 %      ±10.99% ±14.62%  ±19.03%
v8\get-stats.js n=1000000 method='getHeapStatistics'                     10.35 %      ±10.90% ±14.50%  ±18.87%
v8\serialize.js n=1000000 len=16384                                       1.97 %       ±2.21%  ±3.14%   ±4.53%
v8\serialize.js n=1000000 len=256                                ***      5.59 %       ±1.61%  ±2.30%   ±3.36%
v8\serialize.js n=1000000 len=524288                                     19.28 %      ±48.92% ±76.74% ±130.72%

It is only preliminary, but it is not very difficult to conduct a full examination. There are some maintenance benefits to switching to LLVM under Windows as well. I stress that Node works right now under Windows when compiled with LLVM (credit to @targos).

There is at least one minor issue with ICU: #34201 A tiny patch might be required. I actually expect that it might be the only problem.

I am opening this issue following a request by @mcollina

Further reading: Should Node.js be built with ClangCL under Windows?

Checklist:

Activity

  1. mcollina commented on May 2, 2024

    @mcollina
    mcollina
    on May 2, 2024
    SponsorMember

    I recall that it was recommended by MS folks to build using clang on Windows.

  2. avivkeller
    added
    windowsIssues and PRs related to the Windows platform.
    buildIssues and PRs related to Node.js builds or CI infrastructure.
    on May 2, 2024

  3. lemire commented on May 2, 2024

    @lemire
    lemire
    on May 2, 2024
    MemberAuthor

    One issue to consider is that Google switched over so they are developing V8 under ClangCL.

  4. StefanStojanovic commented on May 13, 2024

    @StefanStojanovic
    StefanStojanovic
    on May 13, 2024
    Contributor

    I was thinking about opening an umbrella issue with a checklist or something like that for all things related to enabling ClangCL compilation on Windows, but since there is already this issue if you agree @lemire we can use it for that (if not, I'll create a separate issue with the content of this message).

    Anyway, the following is (not sorted according to priority) a list of things done, being worked on, or that should be worked on before stating ClangCL is officially supported for compiling Node.js on Windows:

    • Add a configuration option in vcbuild.bat to pick from MSVC and CLangCL - This landed in build: add option to enable clang-cl on Windows #52870
    • harmonize Clang checks and update V8 warning flags - This landed in build: harmonize Clang checks and update V8 warning cflags #52873
    • Upstream changes in gyp-next to enable setting language standard keys in msvs_settings - This landed upstream in feat: support language standard keys in msvs_settings gyp-next#252, will eventually get updated in the main project
    • Install ClangCL on Windows hosts in CI - This landed in ansible: add ClangCL to VS2022 build#3714
    • Fix ICU issue for cross-compilation to ARM64 - I'm looking into this, ideally, we'll fix it upstream and pull it to Node.js as a dependency.
      EDIT Opened a draft PR in ICU ICU-21633 Fix ClangCL cross-compilation on Windows unicode-org/icu#3013
    • Fix ARM64 cross-compilation - WIth the latest V8 updates (v12.2 and v12.4) V8 has a new third-party dependency which is causing issues in Node.js. I'm looking into this, ideally, we'll fix it upstream and pull it to Node.js as a dependency.
    • Implement logic for detecting installed ClangCL version - This is currently hardcoded to the version that can be installed via Visual Studio as a component. I've discussed this with @huseyinacacak-janea and he is currently investigating it
    • Configure Windows CI jobs to build and test ClangCL - I will work on this once most other things are done so we can start gaining confidence for ClangCL builds
    • Run benchmarks to ensure performances are not worsened by moving to ClangCL from MSVC - This is self-explanatory.
    • Make sure that the Node.js ecosystem is not facing issues because of the migration - Make sure node-gyp, popular npm packages, etc. are all still working well
    • Investigate the compilation times between MSVC and ClangCL - This should be taken into serious consideration as we'll be compiling with both MSVC and ClangCL in the CI for at least some time. We should investigate the possibility of using ccache or similar tools with ClangCL.
    • If there are no reasons not to, switch to using ClangCL as a default compiler for future releases - Potentially Node.js v23 would be a nice time to do this. The same can also be said for dropping x86 support based on Should we drop support for 32 bit Windows? #42543 (comment)

    I might have missed something, but most things should be covered here. If anyone notices something missing or wrong, please let me know.

    cc: @targos @nodejs/platform-windows

  5. lemire commented on May 13, 2024

    @lemire
    lemire
    on May 13, 2024
    MemberAuthor

    @StefanStojanovic It definitively makes sense to leverage the current issue.

  6. StefanStojanovic commented on May 13, 2024

    @StefanStojanovic
    StefanStojanovic
    on May 13, 2024
    Contributor

    @StefanStojanovic It definitively makes sense to leverage the current issue.

    Great! One issue I see with it is that if the comment gets edited often (eg. I edited it just now to add a PR I opened) it will probably not be sent as a notification, plus I'm probably the only one who can edit it. If anyone has a better idea eg. a GitHub Project or something like that, I'm all for it.

  7. lemire commented on May 13, 2024

    @lemire
    lemire
    on May 13, 2024
    MemberAuthor

    @StefanStojanovic I can edit your comment, but another take on it would be to edit the issue first post (that is, the text I have written). Do you have edit access?

    I think you should be able to edit the issue... I think you have access... don't you?

    That is, I don't own this issue, it should be a collective one.

  8. StefanStojanovic commented on May 13, 2024

    @StefanStojanovic
    StefanStojanovic
    on May 13, 2024
    Contributor

    @StefanStojanovic I can edit your comment, but another take on it would be to edit the issue first post (that is, the text I have written). Do you have edit access?

    I think you should be able to edit the issue... I think you have access... don't you?

    That is, I don't own this issue, it should be a collective one.

    Nope, I do not see edit. This is what I see. Not sure GH supports collective issues, would be great if it did...

    image

  9. lemire commented on May 13, 2024

    @lemire
    lemire
    on May 13, 2024
    MemberAuthor

    @joyeecheung Can you help? I think we would like @StefanStojanovic to have the ability to edit this issue.

  10. H4ad commented on May 13, 2024

    @H4ad
    H4ad
    on May 13, 2024
    Member

    @lemire He will have the ability to edit once he becomes a nodejs collaborator (probably next week)

  11. lemire commented on May 13, 2024

    @lemire
    lemire
    on May 13, 2024
    MemberAuthor

    @StefanStojanovic Given @H4ad's answer, I recommend just waiting a week or so. ;-)

  12. hocheung-chromium commented on May 22, 2024

    @hocheung-chromium
    hocheung-chromium
    on May 22, 2024

    https://issues.chromium.org/issues/341803745

    fp16 in v8 has been updated to the latest version, I think the blocker on the v8 side can be removed.

  13. nodejs-github-bot
    added a commit that references this issue on May 28, 2024

    deps: fix FP16 bitcasts.h

    a320ac6
  14. targos
    added a commit that references this issue on Jun 1, 2024

    deps: fix FP16 bitcasts.h

    728c861

  15. 294 remaining items

  16. nodejs-github-bot
    added a commit that references this issue on May 29, 2025

    deps: fix FP16 bitcasts.h

    7143a8a
  17. nodejs-github-bot
    added 9 commits that reference this issue on May 30, 2025

    deps: fix FP16 bitcasts.h

    608233f

    deps: fix FP16 bitcasts.h

    5ef7f7a

    deps: fix FP16 bitcasts.h

    0bc72dc

    deps: fix FP16 bitcasts.h

    1daf59f

    deps: fix FP16 bitcasts.h

    bd5f22f

    deps: fix FP16 bitcasts.h

    e87ca9e

    deps: fix FP16 bitcasts.h

    7cb54cb

    deps: fix FP16 bitcasts.h

    3a03813

    deps: fix FP16 bitcasts.h

    172525a
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    buildIssues and PRs related to Node.js builds or CI infrastructure.windowsIssues and PRs related to the Windows platform.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions