[galabovaa]

Description

Follow up #3409

@mathgeekcoder

For example, instead of having the python script to generate triplets; we can pre-generate the minimal necessary triplets and store them in our repo, i.e., VCPKG_OVERLAY_TRIPLETS = ${sourceDir}/cmake/toolchains or something.

cmake/vcpkg-triplets ?

x64/arm64-windows-static-clang + the clang-cl toolchain, and HIGHS_VCPKG=ON uses them by default on Windows when clang-cl is found (-DHIGHS_VCPKG_CLANG_CL=OFF to opt out). CI is down to x64 + arm64.

Also, I'm not sure the benefits of compiling OpenBLAS with clang and the rest with msvc? I might be missing something here? Isn't it better to do all or nothing?

Yeah, not too sure about this. I got no significant difference in performance for HiGHS with Clang-cl vs MSVC. MSVC is kind of the standard, and not everyone has (or wants to get) an llvm install. I thought it may be weird to have HiGHS with HiPO clang and HIGHS without HiPO MSVC. This seemed "safer" for not breaking something accidentally as it is a considerable build change.

Configuring HiGHS with clang-cl would build everything with clang. The vcpkg triplets now build all ports with clang-cl.

Note: there's a subtle difference for people using vcpkg to compile highs (separate build), and people using vcpkg to consume highs in their projects (integrated build). The latter folks might define their own triplets/toolchains for clang instead.

Thank you, this would be ok as vcpkg.cmake returns early when a toolchain is already set?

New triplet files in cmake/vcpkg-triplets/:

x64-windows-static-clang.cmake and arm64-windows-static-clang.cmake build every port with clang-cl. The OpenBLAS settings are the same as before: DYNAMIC_ARCH on x64, TARGET=ARMV8 on arm64

clang-cl-toolchain.cmake is the toolchain
cmake/vcpkg.cmake: with HIGHS_VCPKG=ON on Windows x64/arm64, it now uses *-windows-static-clang for both the target and host triplet if it finds clang-cl. If it doesn't, it warns and uses *-windows-static as before. The new option HIGHS_VCPKG_CLANG_CL=OFF turns this off. On Windows it always adds the directory to VCPKG_OVERLAY_TRIPLETS, so you can also pick the triplet by hand. Integrated builds, where a toolchain is already set, still skip all of this.

This way anyone on Windows with LLVM installed who builds with HIGHS_VCPKG=ON would get the clang triplet by default. Their first vcpkg build will be much slower, but HiPO will be several times faster. Do you think this is what we want?

Checklist

• I have read the contributing guidelines
• This PR targets the latest branch
• Tests are passing
• Documentation was updated where relevant
• This PR is not primarily AI-generated (per the AI contributions policy in CONTRIBUTING.md)

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 75.60%. Comparing base (18a474c) to head (9d2aaad).
⚠️ Report is 91 commits behind head on latest.

Additional details and impacted files

@@            Coverage Diff             @@
##           latest    #3530      +/-   ##
==========================================
+ Coverage   75.45%   75.60%   +0.15%     
==========================================
  Files         461      461              
  Lines      113218   113649     +431     
  Branches    17882    17904      +22     
==========================================
+ Hits        85430    85928     +498     
+ Misses      27500    27433      -67     
  Partials      288      288              

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[mathgeekcoder]

Looks great! Much simplified. Thanks!

[mathgeekcoder]

Yeah, not too sure about this. I got no significant difference in performance for HiGHS with Clang-cl vs MSVC. MSVC is kind of the standard, and not everyone has (or wants to get) an llvm install. I thought it may be weird to have HiGHS with HiPO clang and HIGHS without HiPO MSVC. This seemed "safer" for not breaking something accidentally as it is a considerable build change.

This way anyone on Windows with LLVM installed who builds with HIGHS_VCPKG=ON would get the clang triplet by default. Their first vcpkg build will be much slower, but HiPO will be several times faster. Do you think this is what we want?

I think I interpreted the changes correctly, but to double check:

1. this will use clang-cl (not clang) for windows builds
2. it uses clang-cl for all dependencies and highs libraries (i.e., everything)
3. the user doesn't need llvm installed, but only the clang-cl (i.e., msvc clang tools)

If this is the case, why is the first vcpkg build slower?

[galabovaa]

this will use clang-cl (not clang) for windows builds

Yes. I wrongly assumed you needed clang to use clang-cl, but clearly not.

it uses clang-cl for all dependencies and highs libraries (i.e., everything)

Not quite: all the vcpkg ports are built with clang-cl, but the HiGHS libraries use whichever compiler CMake is configured with, so MSVC by default. You only get clang-cl for everything if you also configure HiGHS with it. Do you think we should build HiGHS with clang-cl as well when vcpkg is used?

the user doesn’t need llvm installed, but only the clang-cl (i.e., msvc clang tools)

That should be the case, but it isn’t yet. The ports can use the Visual Studio clang-cl, as they did in CI, but the check in vcpkg.cmake that picks the triplet only looks on PATH and in Program Files/LLVM/bin, so with LLVM hidden it fell back to the MSVC triplet. This branch also looks in Visual Studio installs, using vswhere: clang-simplity...clang-simplify-test. It works in a local test with a stand-in VS install, and I changed the CI job to hide LLVM so that it tests a real one.

If this is the case, why is the first vcpkg build slower?

Because of DYNAMIC_ARCH=ON on x64, not clang-cl: OpenBLAS compiles 14 CPU targets. Locally, OpenBLAS took 15 min that way, against 3.6 min for clang-cl with a single target and 3 min for MSVC. On CI it’s 39 min against 8–11 min for MSVC.

Trimming to DYNAMIC_LIST=HASWELL;SKYLAKEX;ZEN took 6.5 min, with no measurable HiPO difference on my AVX2 machine (5 runs each on 4 LPs). I couldn’t test the AVX-512 kernels, as my CPU doesn’t have them. Do you think it’s worth doing here?

One correction to what I said about speed: compared with MSVC-built OpenBLAS, I measured HiPO about 2x faster on a larger random LP (45 s to 21 s), and only 10–20% on small netlib problems. So closer to your expectation and further from qap12, which seems particularly sensitive. ( I chose qap12 after I asked Filippo what is a good problem to use to measure openblas, so maybe there is a reason for that)