similar to: Problems building R 2.2.1 with libgoto and SSE2 enabled

Dear all, I am currently trying to link R 2.1.0 to the GOTO BLAS 0.99.3 library on a box running Fedora Core 3 , basically following the steps indicated in the R-Admin document: 1: I downloaded the current libgoto.xxx.so from http://www.cs.utexas.edu/users/kgoto/libraries/libgoto_prescott-32-r0.99-3.so.gz, a version suitable for our XEON machine (Nocona core), unpacked it to /usr/lib and created

When getting pqR to work on Windows, I've wanted for it to be able to use SSE2 instructions with 32-bit builds, for those 32-bit processors that have SS2 instructions (all of them from the Pentium 4 onwards). It seems that R Core 32-bit versions do not attempt this, instead using the 387 FPU for all floating-point arithmetic. This is sometimes slower than using SSE2 instructions, and also

G'day all, I have daily scripts running to install the patched version of the current R version and the development version of R on my linux box (Ubuntu 18.04.4 LTS). The last development version that was successfully compiled and installed was "R Under development (unstable) (2020-01-25 r77715)" on 27 January. Since then the script always fails as a regression test seems to fail.

I've noticed unstable behavior of nlminb on some Linux systems. The problem can be reproduced by compiling R-3.5.2 using gcc-8.2 and running the following snippet: f <- function(x) sum( log(diff(x)^2+.01) + (x[1]-1)^2 ) opt <- nlminb(rep(0, 10), f, lower=-1, upper=3) xhat <- rep(1, 10) abs( opt$objective - f(xhat) ) < 1e-4 ## Must be TRUE The example works perfectly when

Dear listers, I have update to rtools43 and, using R 4.2.3 I have been surprised not to be able to compile packages needing compilation when updating. Looks like the path given in gcc? -I"C:/PROGRA~1/R/R-42~1.3/include" -DNDEBUG -DNTIMER -I./SuiteSparse_config -DUSE_FC_LEN_T -I"C:/rtools42/x86_64-w64-mingw32.static.posix/include"???? -O2 -Wall? -std=gnu99 -mfpmath=sse

? Thu, 31 Aug 2023 11:57:06 +0000 Christophe Bousquet <chr_bousquet at protonmail.com> ?????: > > tools::Rcmd('SHLIB -n hello.c') > > tools::Rcmd('SHLIB hello.c') > > > > What do the commands print? Does the second command fail? > > I basically get no output from the two commands, apart from a new > blank R prompt. So starting a new

> From: Douglas Bates > > How does the Opteron perform on floating point? Can you try something > like > > > mm = matrix(rnorm(1e6), nc = 1e3) > > system.time(crossprod(mm)) > [1] 0.51 0.02 0.53 0.00 0.00 > > system.time(crossprod(mm)) > [1] 0.37 0.03 0.40 0.00 0.00 > > system.time(crossprod(mm)) > [1] 0.38 0.02 0.40 0.00 0.00 > >

On 22 March 2016 at 11:34, James Molloy <James.Molloy at arm.com> wrote: > I don’t think this part is right. The denormal flag would have to be set by > whatever code generates the FP instruction, which would be Clang’s codegen > layer. So the if (Darwin) would be there, not in TTI. Right, I meant the information to set/not set would be in TTI, not the actual setting. I don't

On 25 March 2016 at 04:11, Hal Finkel <hfinkel at anl.gov> wrote: > As I understand it, the fundamental property being addresses here is: Are the semantics of scalar FP math the same as vector FP math? TTI seems like a good place to expose that information. If the semantics are indeed different, then the vectorizer would require fast-math flags in order to vectorize FP operations

Hi Renato, As I understand it, the fundamental property being addresses here is: Are the semantics of scalar FP math the same as vector FP math? TTI seems like a good place to expose that information. If the semantics are indeed different, then the vectorizer would require fast-math flags in order to vectorize FP operations (similarly, gcc's man page says it requires

On 2011-02-12 12:34, David Given wrote: ... > You might want to look at the generated machine code to see how they > differ. If this *is* the problem, you can tell gcc to use a particular > instruction set with -mfpmath=386 or -mfpmath=sse. I think you mean -mfpmath=387, instead. :) Btw, this option is also not supported by clang... any idea how it could be implemented, if at all?

I have a very simple test case on Windows that shows some surprising behavior. This doesn't seem to be a problem on Linux. The example is: #include <stdio.h> #include <math.h> double heat(double Pr) { return pow(Pr, 0.33); } int main(int argc, char **argv) { double Nu = heat(291.00606180486119); printf("%.20f\n", Nu); } I've tested with MinGW's gcc.exe

On 12/02/11 04:52, Michael Smith wrote: [...] > With "gcc test.c; ./a.exe", the printed result is 6.50260946378542390000 > With "clang -emit-llvm -c test.c -o test.bc; lli test.bc", the printed result is 6.50260946378542480000 The x86 has got several different FPU instruction sets, which don't all work at the same precision. In particular, using 387 instructions uses

On Sat, Feb 12, 2011 at 1:06 PM, Dimitry Andric <dimitry at andric.com> wrote: > On 2011-02-12 12:34, David Given wrote: >> You might want to look at the generated machine code to see how they >> differ. If this *is* the problem, you can tell gcc to use a particular >> instruction set with -mfpmath=386 or -mfpmath=sse. > > I think you mean -mfpmath=387, instead. :)

Prof Nash, Prof Galanos Is it possible to use a generic code stub in front of packages that use optimx to improve optimx use or curtail it according to the requirements? Best Regards Amit +91 7899381263 ________________________________________________________________________ Please request Skype as available 5th Year FPM (Ph.D.) in Finance and Accounting Area Indian Institute

wxRuby 0.6.0 has been released and is now available for download from RubyForge at http://wxruby.rubyforge.org/ This release includes binary builds for Max OS X and MS Windows. Changes in this release include: * Additional widget support in XRC (thanks to Marshall Elfstrand) * Addition of wxScrollbar (thanks to Hans Harmon of Pinnacle Technologies Inc) * Addition of wxGrid event handlers (thanks

1. A program can use SSE instructions only if both CPU and OS support SSE. Currently libFLAC tests both CPU and OS for this support, but is it really necessary? Maybe CPU check is enough? Operating systems that don't support SSE (Win95, WinNT 4.0, Linux kernel 2.2 (iirc), ...) are really outdated now. Removing OS check will greatly simplify src/libFLAC/cpu.c. 2. "configure" build

Hello, R 3.5.2 on ubuntu 18.04. sessionInfo() at the end. Works with me, same results, cannot reproduce the error. f <- function(x) sum( log(diff(x)^2+.01) + (x[1]-1)^2 ) opt <- nlminb(rep(0, 10), f, lower=-1, upper=3) str(opt) xhat <- rep(1, 10) all.equal(opt$par, xhat, tol=0) # good: 5.53 e-7 #[1] "Mean relative difference: 5.534757e-07" all.equal(opt$objective,

More specifically, about this patch: http://git.xiph.org/?p=flac.git;a=commitdiff;h=70b078cfd5f9d4b0692c33f018cac3c652b14f90 I downloaded the latest code from git (flac-70b078c), disabled all SSE optimizations in the code and compiled it (GCC 4.8.2). This patch doesn't change FLAC output. Either gcc is too smart and optimizes this new code back to the old, or this fix is MSVS-specific. Or

Oops, I think both of us forget to cite the r-devel channel. Best, Jiefei On Tue, Mar 10, 2020 at 5:13 AM Wang Jiefei <szwjf08 at gmail.com> wrote: > Thanks for your quick response, Tomas. > > Yes, this is a path issue, I think the problem is related to R, not the > Rtools make. I built an example package for reproducing the problem: > https://github.com/Jiefei-Wang/example