I'm trying to run a set of fairly large non-linear optimizations through an R interface. (Yes, it must be R -- other languages don't work) I've been groveling around in the code, and I confess that I can't figure out whether NLOPT supports multithreaded operation, and, if so, how it gets kicked in.
Is it?
Related
In other programming languages like Julia, we can define a Gurobi environment object first (i.e., Gurobi.Env() in Julia) and then use them again in solving linear programs.
However, I am not aware of such a feature in R. It seems that I need to pull the Gurobi license every time when I call the gurobi command in R. This cause some troubles when I am running things in parallel on the server because it seems that the Gurobi license is not released immediately after a linear program is solved.
May I know is there a way to define a Gurobi environment object in R first and then use them again? Or is there any ways to release the Gurobi license after running a linear program in R?
Any thoughts are appreciated, thanks!
Both the R and the Matlab interfaces of Gurobi do not work as the other object-oriented APIs like Python, C++, or Java. You can only define/build the model and solve it in one go. You would need to use a different API to have more fine-grained control of the environment and the model.
I recently looked into the usage of GPU computation, where the usage of package seemed to be confusing.
For example, CuArrays and ArrayFire seemed to be doing the same thing, where ArrayFire seemed to be the "official" package on Nvidia developers' webpage.(https://devblogs.nvidia.com/gpu-computing-julia-programming-language )
Also, there were CUDAdrv and CUDAnative Packages..., which seemed to be confusing, as their functionality seemed to be not as straightforward as the others.
What does these packages do? Is there any difference between CuArrays and ArrayFire?
As explained in the blog post you shared, it is quite simply as given below
The Julia package ecosystem already contains quite a few GPU-related
packages, targeting different levels of abstraction as Figure 1 shows.
At the highest abstraction level, domain-specific packages like
MXNet.jl and TensorFlow.jl can transparently use the GPUs in your
system. More generic development is possible with ArrayFire.jl, and if
you need a specialized CUDA implementation of a linear algebra or deep
neural network algorithm you can use vendor-specific packages like
cuBLAS.jl or cuDNN.jl. All these packages are essentially wrappers
around native libraries, making use of Julia’s foreign function
interfaces (FFI) to call into the library’s API with minimal overhead.
CUDAdrv and CUDAnative packages are meant for directly using CUDA runtime API and writing kernels from Julia itself. I believe that is where CuArray come in handy - wrapping native Julia objects into CUDA accessible format, roughly speaking.
ArrayFire on the other hand is a generic library that wraps around all(cuBLAS, cuSparse, cuSolve, cuFFT) CUDA provided domain specific libraries into nice interface(functions). Apart from the interface to CUDA's domain specific libraries, ArrayFire by itself provides lot of other functions in the areas of statistics, image processing, computer vision etc. It has nice JIT feature where user's code is compiled to a runtime kernel - simply put. ArrayFire.jl is an language binding with some extra Julia specific improvements at wrapper level.
That's the general difference. From a developers perspective, using a library(like ArrayFire) basically takes out the burden of keeping up with CUDA API and maintaining/tweaking the kernels for optimum performance which I think takes lot of time.
PS. I am a member of ArrayFire development team.
I am using R for a reproducible scientific machine learing & hyperparameter optimizations. I stumble upon the fact that other implementations of blas such openblas/atlas/klm can speedup this costly optimization. But results are slightly different using each blas even if optimization is forced on single thread results deviate from default R.
So I want to try using Docker to contain the experiment. I have multiple questions.
is it good to compile from source instead of binaries ?
if I compile from source, will it lead to same configuration as debian binaries ?
since results are different for each blas, there is a tool called ReproBLAS from Berkeley, is it good idea to use it with R ?
when you compile R using "--with-blas=-lopenblas" in this case openblas is single threaded or multithreaded ?
I seem to be unable to compile RPostgreSQL for Windows x64, and after extensive searching, I've not been able to find a precompiled binary. To get on with my work, I've installed a 32 bit version of Postgre and have been using 32 bit R for all database ops.
I need to do much of my work in 64 bit R, so switching back and forth has become a bit painful, especially since this requires a save() and load() operation each time I need to run a query.
I'm wondering whether it is possible to call one R installation directly from another? For example, could I simply pass queries to my 32 bit R installation and retrieve the result? I think there are other times when the ability to call another R installation would be useful as well.
All I've come up with is using a system() call, either directly to pgsql or to 32-bit R, but this doesn't allow for very efficient transfer of data.
I'd very sincerely appreciate any advice or assistance!
P.S. I'd rather ask how to compile RPostgreSQL for x64, but as I understand the rules here, such a question would be inappropriate since it's not a general question (e.g. I'd need step-by-step instructions since I don't have the requisite skills).
http://wiki.postgresql.org/wiki/64bit_Windows_port
I can't find it anywhere on the web (and I don't want to install it). Is the R language a compiled language? How fast does it run a pre-written script? Does it do any kind of compilation, or just execute instructions line by line?
In most cases R is an interpreted language that runs in a read-evaluate-print loop. There are numerous extensions to R that are written in other languages like C and Fortran where speed or interfacing with native libraries is helpful.
I've often rewritten R code in C++ and made it run 100x faster. Looping is especially inefficient in R.
R is generally an interpreted language. However, package compiler offers bytecode compilation that can improve performance. You can also call compiled code from R.
In terms of how fast, it depends on what you are trying to do and how you are trying to do it. Some looping operations can be very slow. However, in many cases, with well written code, the performance of R scripting is determined by the speed of the underlying internal C-based libraries and system memory read-write speeds, and so R is about as fast as anything else.