eddelbuettel / rcppsimdjson

Rcpp Bindings for the 'simdjson' Header Library

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Under Windows, consider compiling with clangcl

lemire opened this issue · comments

Despite our best efforts, Visual Studio produces inferior performance compared to clang under Windows.

It may not be possible to reach parity. Meanwhile clangcl is binary compatible with visual studio.

Projects like numpy can be built with clangcl.

Appreciate the note, I really do, and been following your tweets -- impressive debugging work.

But you may as well stand outside of Buckingham Palace and shout "drive on the damn right hand side of the road". There is only one compiler used for R packages on Windows, and this is a repo for an R package. There is strictly less than zero we can do here. So I have no choice but to close this.

@eddelbuettel I'll keep exploring. One solution might be to dump some of the routines, compiled with clang, into assembly that Visual Studio can consume.

Sounds excellent for users of those tools. Once again, we do not use Visual Studio here.

We only use the gcc/g++ of MinGW as provided by the so-called Rtools bundle for R.

@eddelbuettel Wait... You do not use Visual Studio at all...

Oh. Sorry. I assumed that there were different builds including some based on Visual Studio.

Then you are all good... MinGW is fantastic.

Sorry for the noise. For some reason, I was certain that you needed Visual Studio...

You must be getting some complaining from Windows programmers?

+1 for R

Progress comes more slowly in those circles. Per the package CRAN page no Windows binary has yet been made, and folks depending on Windows are usually less likely to build from source.

We did get some fantastic benchmark results from first users on real computers though :) There is a widely used toolchain for consuming JSON easily from R (essentially hiding the lower-level REST stuff) and RcppSimdJson can plug in there. @knapply, who like you never rests, already added support for raw bytes skipping one more step. One user is essentially seeing 6x just by swapping us in for the (common, trusted, well-done but simply slower) "default" JSON package.

Fantastic!