Several days back, I posted a comment/question from Kazushige Goto (the
developer and maintainer of Goto BLAS) -
"By the way, please ask your R developer to rewrite memory allocation
function including garbage collection. They give 4 byte offset memory
region and never perform well (or it wi
I was on the Goto BLAS maillist yesterday, asking some question about
relative speed/performance/tuning of Goto BLAS and (specifically) R.
I received a reply from Kazushige Goto (the developer and maintainer of
Goto BLAS), who as part of his answer to some of my queries made the
following comm
So, tried again from scratch. Again, CentOS 5.3, which is essentially
RHEL 5.3.
./configure --with-blas="-L/opt/acml4.3.0/gfortran64/lib -lacml"
In config.log, get things like
configure:37199: checking for dgemm_ in -L/opt/acml4.3.0/gfortran64/lib
-lacml
configure:37230: gcc -std=gnu99 -o con
Normally, I do the following to configure R for compilation on my
Opteron box with ACML installed:
./configure --with-tcltk --with-blas="-L/opt/acml4.3.0/gfortran64/lib
-lacml"
However, when I do so, and look at Makeconf, I see
BLAS_LIBS = -lblas
I thought I would see
BLAS_LIBS = -L/opt/ac
Well, I've now tried just about every permutation I can think of -
including using the ATLAS lapack (instead of generic), in various
combinations with ACML, or generic BLAS, or ATLAS blas. No matter what I
do, so long as I have lapack of any flavour, I get the 'stats error'
with make check. And
So, I tried the following configure:
./configure --with-lapack --with-blas --with-tcltk
No use of ACML at all, but both lapack and blas. Configure proceeds
without any errors. Make, same thing.
Make check - same problem with stats. But, this time a .fail file got
created in tests/Example.
L. Of
course, figuring out what is the problem. I suppose the other option is
another BLAS - say, ATLAS. Never tried that, but I suppose I could take
it out for a spin.
Pity, since ACML really was doing the trick for some of my linear
algebra-heavy progs.
Evan Cooch wrote:
For grins, tried rebui
For grins, tried rebuilding R 2.9.0 without using ACML 4.3.0. Config
goes fine, make runs without any errors.
make check - and - ta-dah! - no errors for stats. Everything seems to
check out just fine.
So, it seems as if R 2.9.0, ACML 4.3.0, and perhaps one/more things
under CentOS don't play
Greetings -
For a host of reasons I chose (was forced) to upgrade my multi-Opteron box
from Fedora 7 -> Fedora 8. In the process, I also updated the ACML I had
installed from 4.0.0 to 4.1.0.
While I get no errors (that I can find) in the config -> make -> make
install sequence, I'm pretty sure (b
Solved - finally (after 4-5 different mirrors) found a tarball that
didn't give the report configure error.
Strange...
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
For what its worth, I get the same error even if I do a naked 'config'
(no lapack, no blas, no reference to ACML).
>
> config.status: error: cannot find input file: doc/manual/Makefile.in
>
>
So, I think its a tarball issue.
__
R-devel@r-project.or
Have been running 2.5.1 on my multi-pro Opteron box running Fedora Core
5 with no problems. Had compiled previously with no problems. However,
for a variety of reasons (mostly due to ACML upgrade), I tried a
recompile using the following sequence of commands (note I'm compiling
in ACML support
gt; ATLAS 3.6.0, single-threaded
>
>> system.time(for(i in 1:25) X%*%X)
>>
> [1] 16.164 0.404 16.572 0.000 0.000
>
>> system.time(for(i in 1:25) solve(X))
>>
> [1] 26.200 1.704 27.907 0.000 0.000
>
>> system.time(for(i in 1:10) svd(X))
>
Hin-Tak Leung wrote:
> Evan Cooch wrote:
>> Quick followup - works fine with fluxbox (and, as noted, default
>> twm). Simply can't get it to work with the gnome desktop, which
>> ultimately I would like to.
>
> The difference between twm and metacity in gnome or
Quick followup - works fine with fluxbox (and, as noted, default twm).
Simply can't get it to work with the gnome desktop, which ultimately I
would like to.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
>
> I don't think xset q is the right diagnostic tool. I suspect that it
> just reflects a default setting of vnc. Those directories could be
> empty for all that it knows. xfontsel might be more to the point if
> you need to know whether the fonts are actually available.
>
> However, I can't repr
Greetings -
Users of the box I'm putting together will need to be able to run R
remotely, using a virtual desktop. One approach (that I'm trying) is to
use VNC. So far, I can get the remote gnome desktop up on the server
(running Fedora Core 5), and can start R from a terminal. However, for a
Hin-Tak Leung wrote:
> Evan Cooch wrote:
>> I lie (apparently) - turns out step (7) (below) *did* work.
>>
>> OK, so why didn't previous attempts at the problem (i.e., using
>> LD_LIBRARY_PATH) work? Hmmm
>
> LD_LIBRARY_PATH affects runtime behavior,
I lie (apparently) - turns out step (7) (below) *did* work.
OK, so why didn't previous attempts at the problem (i.e., using
LD_LIBRARY_PATH) work? Hmmm
> 7. one final attempt:
>
> ./configure --with-blas="-L/opt/acml3.5.0/gnu64/lib -lacml"
>
> No change - readline is still the only
>
>
>
>
>
ttempt:
./configure --with-blas="-L/opt/acml3.5.0/gnu64/lib -lacml"
No change - readline is still the only
--
------
Evan Cooch e.mail: [EMAIL PROTECTED]
Department of Natural Resources voic
>
> I think the early version of ACML lagged behind others, but recent
> versions are competitive. I've run into precision problem (failing
> make check all) with some Goto BLAS before. Also, Goto BLAS has
> switched to a more restrictive license (probably not a problem for
> you though).
>
Greetings -
A quick perusal of some of the posts to this maillist suggest the level
of the questions is probably beyond someone working at my level, but at
the risk of looking foolish publicly (something I find I get
increasingly comfortable with as I get older), here goes:
My research group r
22 matches
Mail list logo
