Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

R, OpenMP, MKL, Disaster

jyotirmoy.net

Post reply on HN
Print view View original

31–40 of 43 posts

Re: R, OpenMP, MKL, Disaster

#31

Post by dragonwriter »

mellavora wrote: post #28
civilized wrote: post #26

Earlier quoted context omitted.

R isn't the best for production predictions for sure (it can work though). But it's not hard to translate well-designed R processing pipelines and models into other languages if you must. The problem is that R programmers often don't know how to write good code in any language. Same issue as Excel, really. Easy to use, so you get a lot of users with very thin engineering skills. The solution is for production enginee…

"Same issue as Excel, really. Easy to use, so you get a lot of users with very thin engineering skills." Huh? While I totally agree with your quote, I'd think it applied a lot more to python than to R. Especially given that python seems to be the dominant "first language for people to learn when they get into programming" because it is "easy".

R is a language people use when they get into statistics, not even thinking specifically of programming.

Re: R, OpenMP, MKL, Disaster

#32

Post by user5994461 »

microtonal wrote: post #19
gnufx wrote: post #17

Earlier quoted context omitted.

Debian and Fedora provide serial, OpenMP, and pthreads versions of lilbopenblas. Are you sure OpenBLAS doesn't detect nested OpenMP? I thought it did, though I'd normally use the serial version outside something like R, but if you mix different low-level simple pthreads with high-level OpenMP, you can expect problems. OpenBLAS is fine generally -- competitive with MKL on Intel hardware and infinitely faster on ARM an…

On AMD hardware, I don't understand why people avoid AMD's support, which is just a version of BLIS and libflame. A year ago, I benchmarked a transformer network with libtorch linked against various BLAS libraries (numbers are in sentences per second, MKL with CPU detection override on AMD, 4 threads): Ryzen 3700X - OpenBLAS: 83, BLIS: 69, AMD BLIS: 80, MKL: 119 Xeon Gold 6138 - OpenBLAS: 88, BLIS: 52, AMD BLIS: 59,…

Have you set the environment variable OPENBLAS_CORETYPE to specify the CPU?

Re: R, OpenMP, MKL, Disaster

#33

Post by laichzeit0 »

deng wrote: post #27
laichzeit0 wrote: post #25

Earlier quoted context omitted.

I would completely concede that R has better libraries. However, getting stuff like online prediction into production is a real pain when the models are developed in R. And R is single threaded. There is no way to hide that detail.

> And R is single threaded. There is no way to hide that detail. Python isn't much better in this regard, thanks to the GIL. What I actually found most baffling when I delved into R is the fact that it doesn't support 64bit integers (lack of proper native UTF-8 support coming a close second).

> Python isn't much better in this regard, thanks to the GIL.

Take some standard ML model built with Caret or LME4 and try serve predictions with Plumber in R. It’s significantly more painful than using sklearn + FastAPI. You either need to use future::promise (which still sucks because it’s forking new R runtimes) or forgo this and go K8s or something similar.

I don’t get the love for RStudio either. It crashes frequently for me, or locks up randomly. The debugging experience is abysmal compared to PyCharm. Getting reproducible R builds are a pain, slightly alleviated by Renv. But not really if you want separate dependencies for dev and production.

Python and R tooling are not comparable. You will have serious issues operationalising R. Skills that most statisticians are simply not equipped to deal with, and serious software engineers will hate about R.

Re: R, OpenMP, MKL, Disaster

#34

Post by civilized »

laichzeit0 wrote: post #33
deng wrote: post #27

Earlier quoted context omitted.

> And R is single threaded. There is no way to hide that detail. Python isn't much better in this regard, thanks to the GIL. What I actually found most baffling when I delved into R is the fact that it doesn't support 64bit integers (lack of proper native UTF-8 support coming a close second).

> Python isn't much better in this regard, thanks to the GIL. Take some standard ML model built with Caret or LME4 and try serve predictions with Plumber in R. It’s significantly more painful than using sklearn + FastAPI. You either need to use future::promise (which still sucks because it’s forking new R runtimes) or forgo this and go K8s or something similar. I don’t get the love for RStudio either. It crashes freq…

FWIW I have many years of full-time RStudio dev experience, and while I've definitely had a few hard-to-explain crashes, I'd characterize it as very reliable overall. When problems arise they tend to be due to community-contributed packages, especially packages that call out to C++. (My name is on the bug fix log for some major packages.)

Unintentional and unnecessary creation of huge, memory-hogging objects is a closely related footgun. Packages are often not built with large data in mind and make choices that scale terribly, such as storing multiple copies of the data in the model object, or creating enormous nonsparse matrices to represent the model term structure. It's a legacy of the academic statistics culture R grew out of. Most researchers test their fancy new method on a tiny dataset, write a paper, and call it a day.

No argument about the debugging experience. I find it very slow, especially with large datasets, and try to avoid it. Not much experience with reproducible R builds but I wouldn't be surprised if it was a pain.

Re: R, OpenMP, MKL, Disaster

#35

Post by microtonal »

user5994461 wrote: post #32
microtonal wrote: post #19

Earlier quoted context omitted.

On AMD hardware, I don't understand why people avoid AMD's support, which is just a version of BLIS and libflame. A year ago, I benchmarked a transformer network with libtorch linked against various BLAS libraries (numbers are in sentences per second, MKL with CPU detection override on AMD, 4 threads): Ryzen 3700X - OpenBLAS: 83, BLIS: 69, AMD BLIS: 80, MKL: 119 Xeon Gold 6138 - OpenBLAS: 88, BLIS: 52, AMD BLIS: 59,…

Have you set the environment variable OPENBLAS_CORETYPE to specify the CPU?

I went further than that, I profiled with perf and checked that the right kernels were used.

Re: R, OpenMP, MKL, Disaster

#36

Post by tharne »

keewee7 wrote: post #6

As a software developer forced to work with data scientists who refuse to learn Python there is nothing I hate more than R. R is good for explorative data analysis but useless for everything else.

I don't know why you're getting downvoted. I was one of the data guys you mentioned who learned R first and resisted python. There are a lot of things about R that leads users to develop very bad habits. The only reason R caught on in the first place is because python did not have mature libraries for data analysis for a long time.

Re: R, OpenMP, MKL, Disaster

#37

Post by gnufx »

microtonal wrote: post #19
gnufx wrote: post #17

Earlier quoted context omitted.

Debian and Fedora provide serial, OpenMP, and pthreads versions of lilbopenblas. Are you sure OpenBLAS doesn't detect nested OpenMP? I thought it did, though I'd normally use the serial version outside something like R, but if you mix different low-level simple pthreads with high-level OpenMP, you can expect problems. OpenBLAS is fine generally -- competitive with MKL on Intel hardware and infinitely faster on ARM an…

On AMD hardware, I don't understand why people avoid AMD's support, which is just a version of BLIS and libflame. A year ago, I benchmarked a transformer network with libtorch linked against various BLAS libraries (numbers are in sentences per second, MKL with CPU detection override on AMD, 4 threads): Ryzen 3700X - OpenBLAS: 83, BLIS: 69, AMD BLIS: 80, MKL: 119 Xeon Gold 6138 - OpenBLAS: 88, BLIS: 52, AMD BLIS: 59,…

I was thinking of the usual complaint about Intel not supporting AMD hardware that is common in HPC.

We don't know what that example was actually measuring, except apparently not the same thing for BLIS and MKL. On the basis of only that, it's not reasonable to say "just so much faster", in particular for what I care about. I have Zen2 measurements (unfortunately only in a VM) using the BLIS test/3 framework. MKL came out nearly as fast as vanilla BLIS 0.7 and OpenBLAS on serial DGEMM, less so on the rest of D level 3, and nowhere close with S, C, and Z. Similarly for one- and two-socket OpenMP. At least in that "2021" version of MKL, there's only a Zen DGEMM kernel.

Re: R, OpenMP, MKL, Disaster

#38

Post by civilized »

tharne wrote: post #36
keewee7 wrote: post #6

As a software developer forced to work with data scientists who refuse to learn Python there is nothing I hate more than R. R is good for explorative data analysis but useless for everything else.

I don't know why you're getting downvoted. I was one of the data guys you mentioned who learned R first and resisted python. There are a lot of things about R that leads users to develop very bad habits. The only reason R caught on in the first place is because python did not have mature libraries for data analysis for a long time.

All languages strike a tradeoff between flexibility and enforcing a regular structure. A lot of people seem to think their preferred language hits the perfect point on that tradeoff, and judge any language that makes a different choice. Python lovers judge R, Java users judge Python, C++ users judge Java, Rust users judge C++, Go users judge Rust, and everyone judges JavaScript.

A language that's more flexible than your favorite "encourages bad habits", while a language that's less flexible than yours is "bureaucratic".

Re: R, OpenMP, MKL, Disaster

#39

Post by lstmemery »

I had a similar problem in a prediction pipeline a few years back. If I remember correctly, someone updated a R package to the next minor version. The package was to read an obscure file format. The fix installed a new C++ library. That C++ library somehow interacted with a second R package (using a specialized type of linear model) when compiled at source and all the results coming out of our package were subtly wrong but only with large files.

It turns out the way the second R package would determine the required precision of floats in sparse arrays was based on the compiled linear algebra libraries available. It took a week for us to debug and ultimately it was easier for us to just rewrite the whole thing in Python.

Renv has made things easier but I don't think packrat/renv allows you to lock C/C++ libraries as well as R ones.

Re: R, OpenMP, MKL, Disaster

#40

Post by goerz »

mellavora wrote: post #23
keewee7 wrote: post #6

As a software developer forced to work with data scientists who refuse to learn Python there is nothing I hate more than R. R is good for explorative data analysis but useless for everything else.

with regard to good software engineering, there is a funny thing about python. Simply cut-and-paste code from one env to another can completely destroy the program, if the cut-and-paste messes with the indentation. Now some people say this can be solved with a good IDE. Which might (or might not) be true if you can reliably identify, by manually reviewing the code, the ends of the functions, loops, etc which got mung…

So don’t mess up the indentation when you paste. Seriously, in my 15 years of using Python on a daily basis this hasn’t been a problem once.
Post reply on HN