[Rd] check stats fail | part III
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 nice. Will trying unloading 4.3.0, installing 4.2.0 (which worked before on the Fedora box), and see what happens. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] check stats fail | part III
Well, tried using 4.2.0 instead - no luck. Regardless of which ACML I use, I'm getting the errors described in the original post. So, its not an ACML error (directly), but something has changed in the migration from Fedora Core 8 -> CentOS which isn't playing nice with ACML. 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 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 nice. Will trying unloading 4.3.0, installing 4.2.0 (which worked before on the Fedora box), and see what happens. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] 2.9.0 and make check errors | mystery deepens
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. Bottom of the file has something which might resonate with someone out there: Error in La.svd(x, nu, nv) : BLAS/LAPACK routine 'DGESDD' gave error code -12 Calls: cancor -> svd -> La.svd -> .Call Execution halted So, from the admin guide, I find the following Since ACML contains a full LAPACK, if selected as the BLAS it can be used as the LAPACK /via/ --with-lapack. If you do use --with-lapack, be aware of potential problems with bugs in the LAPACK 3.0 sources (or in the posted corrections to those sources). In particular, bugs in |DGEEV| and |DGESDD| have resulted in error messages such as DGEBRD gave error code -10 So, seems that I'm seeing something analogous (or exactly like) to the 'bug' indicated above. So, suggestions on how to proceed? It seems that the problem lies with LAPACK. Indeed, system comes with LAPACK 3.xx (I have both 32- and 64-bit flavors, which differ a bit; 32-bit is 3.0.37 and 64-bit is 3.1.1), so not sure what to do. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] ready to toss the towel | lapack and 2.9.0
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, it always seems to throw the error at the same point in the stats test file (an svd in cancorr, or some such). Specifically, BLAS/LAPACK routine 'DGESDD' gave error code -12. So, I can pass the 'check tests' so long as I'm willing to drop lapack. Fine, except that big algebra things take insane amounts of time without lapack (1-20 fold decrease in throughput). If it matters, here are some specific specs... gcc version 4.1.2 20080704 (Red Hat 4.1.2-44) lapack-3.0-37.el5 blas-3.0-37.el5 atlas-3.8.3-1.el5 I'd really not have to go through the cycle of trying one distro after another (and I gave up on Fedora because of the all-too-quick end of life on each release, not to mention all the 'broken bits' you need to live with on the 'bleeding edge'). I'm open to suggestions/obvious solutions. I really need to get this working. Thanks in advance... __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] proper link to ACML blas | compiling 2.9.0
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/acml4.3.0/gfortran64/lib -lacml Why isn't Makeconf picking up the right BLAS_LIBS (or is it? does -lblas mean its finding the right blas?). I tried LD_LIBRARY_PATH=/opt/acml4.3.0/gfortran64/lib export LD_LIBRARY_PATH and then did a new Configure, but Makeconf still shows only BLAS_LIBS = -lblas When I look at config.log, I see a 'failure' that I think might be part of the story: configure:37157: result: no configure:37199: checking for dgemm_ in -L/opt/acml4.3.0/gfortran64/lib -lacml configure:37230: gcc -std=gnu99 -o conftest -g -O2 -I/usr/local/include -L/usr/local/lib64 conftest.c -L/opt/acml4.3.0/gfo$ conftest.c: In function 'main': conftest.c:189: warning: implicit declaration of function 'dgemm_' /usr/bin/ld: warning: libgfortran.so.3, needed by /opt/acml4.3.0/gfortran64/lib/libacml.so, not found (try using -rpath or -$ /opt/acml4.3.0/gfortran64/lib/libacml.so: undefined reference to `_gfortran_compare_str...@gfortran_1.0' /opt/acml4.3.0/gfortran64/lib/libacml.so: undefined reference to `_gfortran_transfer_charac...@gfortran_1.0' /opt/acml4.3.0/gfortran64/lib/libacml.so: undefined reference to `_gfortran_transfer_inte...@gfortran_1.0' /opt/acml4.3.0/gfortran64/lib/libacml.so: undefined reference to `_gfortran_stop_nume...@gfortran_1.0' /opt/acml4.3.0/gfortran64/lib/libacml.so: undefined reference to `_gfortran_st_write_d...@gfortran_1.0' /opt/acml4.3.0/gfortran64/lib/libacml.so: undefined reference to `_gfortran_pow_i4...@gfortran_1.0' /opt/acml4.3.0/gfortran64/lib/libacml.so: undefined reference to `_gfortran_transfer_r...@gfortran_1.0' /opt/acml4.3.0/gfortran64/lib/libacml.so: undefined reference to `_gfortran_st_r...@gfortran_1.0' /opt/acml4.3.0/gfortran64/lib/libacml.so: undefined reference to `_gfortran_st_read_d...@gfortran_1.0' /opt/acml4.3.0/gfortran64/lib/libacml.so: undefined reference to `_gfortran_st_wr...@gfortran_1.0' /opt/acml4.3.0/gfortran64/lib/libacml.so: undefined reference to `_gfortran_concat_str...@gfortran_1.0' /opt/acml4.3.0/gfortran64/lib/libacml.so: undefined reference to `_gfortran_string_in...@gfortran_1.0' collect2: ld returned 1 exit status configure:37236: $? = 1 configure: failed So, perhaps things go awry at this point...weird thing is, thee is no libgfortran.so.3 anywhere on the system that I can find __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] can't use ATLAS or ACML | 2.9.0
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 conftest -g -O2 -I/usr/local/include -L/usr/local/lib64 conftest.c -L/opt/acml4.3.0/gfortran64/lib -lacml -$ conftest.c: In function 'main': conftest.c:189: warning: implicit declaration of function 'dgemm_' /usr/bin/ld: warning: libgfortran.so.3, needed by /opt/acml4.3.0/gfortran64/lib/libacml.so, not found (try using -rpath or -rpath-link) Try ./configure --with-blas="-L/usr/lib64/atlas -lf77blas -latlas" I get the following configure:37199: checking for dgemm_ in -L/usr/lib64/atlas -lf77blas -latlas configure:37230: gcc -std=gnu99 -o conftest -g -O2 -I/usr/local/include -L/usr/local/lib64 conftest.c -L/usr/lib64/atlas -lf77blas -latlas -lg$ conftest.c: In function 'main': conftest.c:189: warning: implicit declaration of function 'dgemm_' /usr/bin/ld: cannot find -lf77blas collect2: ld returned 1 exit status configure:37236: $? = 1 configure: failed program was: What puzzles me is that lf77blas is definitely in /usr/lib64/atlas - but configure couldn't find it (?). Perhaps its because 100% of the libs in the atlast subdir are xxx.so.3 (perhaps R config is looking for so.1 libs?). I suspect that many/most of the problems I'm having with getting R to compile (with BLAS and LAPACK) are related to these basic issues - if I can't do even a simple compile with blas, then whats left? __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Goto BLAS
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 comment concerning R, which I pass along to the R development team: "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 will cause segmentation fault. 4 byte offset is fatal). Since R use complex double precision, memory alignment should be at least 16 bytes..." Apparently, Goto has run into some issues with R before. I'll assume that some out there will be able to interpret Goto's comment/suggestion. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Goto memory alignment query...
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 will cause segmentation fault. 4 byte offset is fatal). Since R use complex double precision, memory alignment should be at least 16 bytes..." Goto obviously has thought an awful lot about such things, and (apparently) wrt to R (and he is extremely well-known in programming circles - you don't write a BLAS unless you know a thing or two). Since a number of R users (like me) make use of Goto BLAS, I'd hope that on the devel group could comment/reply. I'll forward to Goto. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] config error during 2.5.1 compile
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 for blas): LD_LIBRARY_PATH=/opt/acml3.6.1/gfortran64/lib export LD_LIBRARY_PATH ./configure --with-lapack --with-blas="-L/opt/acml3.6.0/gfortran64/lib -lacml" This is exactly the same steps I took successfully many times before, but now, when I run the config, it terminates with the following error message: config.status: error: cannot find input file: doc/manual/Makefile.in Now, this puzzles me since doc/manual/Makefile.in is most definitely there, but the configure script isn't finding it, for some reason. Is this a tarball bug? I grabbed another from a different mirror, but ended up with the same error. Oh, and I can say with authority the problem isn't with ACML - I get the error even if I point everything at the older (3.6.0) ACML libs. So, the problem seems to originate in the configure script. Can anyone confirm, or 'fix' (workaround?) Ta in advance... __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] config error during 2.5.1 compile
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.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] config error during 2.5.1 compile
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
[Rd] compiling 2.7.0 GNU/Linux | BLAS & Lapack query
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 (based on some benchmarks) that I'm not getting BLAS and/or Lapack to compile in. So, either something has changed from 2.6.2 -> 2.7.0, or something has changed from Fedora 7 -> Fedora 8, or both. Here is the sequence I follow to do the config (which seemed to work perfectly before - note: using bash shell): 1. LD_LIBRARY_PATH=/opt/acml4.1.0/gfortran64/lib 2. export LD_LIBRARY_PATH 3. ./configure --with-lapack="-L/usr/lib64" --with-blas="L/opt/acml4.1.0/gfortran64/lib -lacml" However, when I try this, at the end of the config script I'm told Interfaces supported: X11 External libraries: readline Additional capabilites: PNG, JPEG, iconv, MBCS, NLS, cairo Options enabled: shared BLAS, R profiling, Java I'm pretty sure that readline being the only external library being reported is diagnostic of some sort of issue - normally, I'm given information about lapack, and generic BLAS being linked. But, no more. Suggestions? Points to the obvious? Both ACML and Lapack are where they should be, so I'm quite frankly puzzled as to what is going on. Thanks very much in advance. [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] compiling R | multi-Opteron | BLAS source
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 recently purchased a multi-Opteron system (bunch of 880 chips), running 64-bit RHEL 4 (which we have site licensed at our university, so it cost us nothing - good price) with SMP support built into the kernel (perhaps obviously, for a multi-pro system). Several of our user use [R], which I've only used on a few occasions. However, it is part of my task to get [R] installed for folks using this system. While the simple, basic compile sequence (./configure, make, make check, make install) went smoothly, its pretty clear from our benchmarks that the [R] code isn't running as 'rocket-fast' as it should for a system like this. So, I dig a bit deeper. Most of the jobs we want to run could benefit from BLAS support (lots of array manipulations and other bits of linear algebra), and a few other compilation optimizations - and here is where I seek advice. 1) Looks like there are 3-4 flavours: LAPACK, ATLAS, ACML (AMD-chips...), and Goto. In reading what I can find, it seems that there are reasons not to use ACML (single-thread) despite the AMD chips, reasons to avoid ATLAS (some hassles compiling on RHEL 4 boxes), reasons to avoid LAPACK (ibid), but apparently no problems with Goto BLAS. Is that a reasonable summary? At the risk of starting a larger discussion, I'm simply looking to get BLAS support, yielding the fastest [R] code with the minimum of hassles (while tweaking lines of configure fies, weird linker sequences and all that used to appeal when I was a student, I don't have time at this stage). So, any quick recommendation for *which* BLAS library? My quick assessment suggests goto BLAS, but I'm hoping for some confirmation. 3) compilation of BLAS - I can compile for 32-bit, or 64-bit. Presumably, given we've invested in 64-bit chips, and a 64-bit OS, we'd like to consider a 64-bit compilation. Which, also presumably, means we'd need 64-bit compilation for [R]. While I've read the short blurb on CRAN concerning 64-bi vs 32-bit compilations (data size vs speed), I'd be happy to have both on our machine. But, I'm not sure how one specifies 64-bits in the [R] compilation - what flags to I need to set during ./configure, or what config file do I need to edit? Thanks very much in advance - and, again, apologies for the 'low-level' of these questions, but one needs to start somewhere. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] compiling R | multi-Opteron | BLAS source
> > 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). > No, probably not a problem for us at this end, but good to know. I'm happy to give the latest version of ACML a try. In fact, it occurred to me that it would probably be worth comparing relative performance. I know that benchmarking is a technical issue, but I would be curious to see how some of our compute-intensive jobs perform. > > >> 3) compilation of BLAS - I can compile for 32-bit, or 64-bit. >> Presumably, given we've invested in 64-bit chips, and a >> 64-bit OS, we'd like to consider a 64-bit compilation. Which, >> also presumably, means we'd need 64-bit compilation for [R]. >> While I've read the short blurb on CRAN concerning 64-bi vs >> 32-bit compilations (data size vs speed), I'd be happy to >> have both on our machine. But, I'm not sure how one specifies >> 64-bits in the [R] compilation - what flags to I need to set >> during ./configure, or what config file do I need to edit? >> > > That's up to the compiler(s) you use (unstated). For GCC, I believe > -m64/-m32 is the flag. For 64-bit GCC -m64 is the default. > > Andy > Thanks indeed. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R and ACML
While I recently received some very helpful files and email from Kevin Hendricks for compiling with ATLAS, thought I'd first have a stab at ACML. Having problems, which I suspect are trivial to solve: 1. machine is running RHEL 4, meaning, it uses gcc 3.4.5 out of the box, and g77. In my experience, over-riding RHEL's choice, and manually upgrading to gcc 4.x.x (and, as a consequence gfortran) will cause problems in other areas (but, if other's have done it successfully, with no problems, I'd be willing to try). 2. machine has multiple CPU's (Opteron 880's) - meaning (based on ACML docs), I *should* download and install gfortran64 (which has mp support). However, I don't have gfortran, so...what about 32-bit? Same problem - mp requires gfortran. Hmmm 3. so, download and install gnu64 version of ACML, which is intended for a single processor (ok, so I guess this means I won't be threading jobs over multiple CPU's...fine). Everything installs into opt/acml3.5.0/gnu64... 4. need to fix up library path. Working in a bash shell, so LD_LIBRARY_PATH/opt/acml3.5.0/gnu64/lib export LD_LIBRARY_PATH Check env - everything seems fine - LD_LIBRARY_PATH is there, and correctly specified 5. cd to R source dir, and run ./configure --with-blas="-lacml" configure runs fine, except that ACML isn't built-in to R, based on the configure output: C compiler: gcc -g -02 -std=gnu99 Fortran 77 compiler: g77-g -02 C++ compiler: g++ -g -02 Fortran 90/95 compiler: g77 -g -02 Interfaces supported: X11 External libraries: readline etc. etc. So, readline is the only external library. 6. ok, look at config.log, Following line looks suspicious: /usr/bin/ld: cannot find -lacml 7. one final attempt: ./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 voice: 607-255-1368 Fernow Hall - Cornell UniversityFAX: 607-255-0349 Ithaca, NY14853 http://canuck.dnr.cornell.edu -- The English are not very spiritual people, so they invented cricket to give them some idea of eternity. - George Bernard Shaw __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R and ACML
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 > > > > > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R and ACML
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, ./configure ... affects > compile time behavior. The former can only influence the latter > to the extent that the runtime environment of temporary tools > built during the configure stage (./configure runs the compiler and > build some small binaries, etc and check stuff by whether the compiler > was successful and running these small binaries and see the results) > are affected. > > Apples and oranges. > > HTL Thanks very much for the clarification. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R | vnc | X11 fonts
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 lot of the R scripts I've tried, I get 'font errors' - the general error message is Error in X11() : could not find any X11 fonts Check that the Font Path is correct OK, bring up another terminal window on VNC, and try xset q, which shows Font Path /usr/share/fonts/default/Type1/, /usr/share/X11/fonts/75dpi/, /usr/share/X11/fonts/100dpi/, ... and so on, and so on - about 10 different font directories in all. So, given that xset q shows that I have lots of X11 fonts in the Font Path, then why does X11() in R tell me I don't have any? __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R | vnc | X11 fonts
>
> 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 reproduce similar behaviour on FC5 with the
> straightforward vncserver/vncviewer/twm default setup (i.e., it runs
> demo(graphics)). So I suspect you need to dig deeper or tell us more
> details about what goes wrong, e.g. how exactly are you running your R
> scripts, will they work from the console, etc.
>
>
OK - here's the nitty gritty. Specifically, its fonts in some graphics
outputs for a script that seem to be missing. Graphics are not
particularly fancy - use defaults for fonts:
e.g.,
matrix.image(y,y,elas.eigen,xlab="year t",ylab="year
t+1",col=topo.colors(100));
title("Elasticity from eigenvectors");
contour(y,y,t(elas.eigen),add=T,cex=3);
abline(h=0); abline(v=0);
1. if I run from console, use standard FC 5 gnome desktop, then
everything works just as it should.
2. if I connect via vnc to the machine, using twm, and run the same
script, then all seems fine. From within the xterm that pops up when you
first fire up twm, xset gives the font paths I specified in
/usr/bin/vncserver. Looking at the .log file in .vnc shows everything
seems to be working OK, except for one error message:
X Error of failed request: BadLength (poly request too large or internal
Xlib length error)
But otherwise, ok.
3. But, if I modify xstartup in .vnc, to use something other than twm,
then...problems. In xstartup in .vnc we see the default
#!/bin/sh
# Uncomment the following two lines for normal desktop:
# unset SESSION_MANAGER
# exec /etc/X11/xinit/xinitrc
[ -x /etc/vnc/xstartup ] && exec /etc/vnc/xstartup
[ -r $HOME/.Xresources ] && xrdb $HOME/.Xresources
xsetroot -solid grey
vncconfig -iconic &
xterm -geometry 80x24+10+10 -ls -title "$VNCDESKTOP Desktop" &
twm &
I'd like to run the standard FC 5 gnome desktop, so I try the following:
1. uncomment the first two lines, then comment out everything else:
#!/bin/sh
# Uncomment the following two lines for normal desktop:
unset SESSION_MANAGER
exec /etc/X11/xinit/xinitrc
#[ -x /etc/vnc/xstartup ] && exec /etc/vnc/xstartup
#[ -r $HOME/.Xresources ] && xrdb $HOME/.Xresources
#xsetroot -solid grey
#vncconfig -iconic &
#xterm -geometry 80x24+10+10 -ls -title "$VNCDESKTOP Desktop" &
#twm &
Restart vncserver, then try to vnc to desktop. Looks good - there it is,
my background image (cute picture of new baby boy), tarted up icons etc.
Bring up a term window - first clue something is wrong - the fonts in
the term window are 'very jagged' (i.e., look 'wrong'). xset q shows
font path(s) are set correctly. Fire up xfontsel (which I know little
about) - tells me 3579 name match. But, when I execute the xfontsel
command, it tells me
Warning: Missing charsets in String to FontSet conversion
Warning: Unable to load any usable font
The last warning is clearly worrisome - and consistent with the 'wrong
font' appearence in the term window, and the fact that when I now X11()
from within R, I get an error message, and when I try the R script,
needless to say it bombs - can't find the basic fonts it needs to label
axes in the graphs.
Summary: so, using twm, R seems to work fine - fonts there, graphics
generated. But, when I try to bring it up on the gnome desktop, all
sorts of problems. I know I could use a different window manager -
better than twm, not as whizzy as the gnome desktop (e.g., fluxbox), but
that is somewhat beside the point. I'm trying to figure out why xterm is
not picking up the fonts through vnc. I'm going to "guess" (literally)
that its some interaction of vncserver (which is just a script - I've
explicity FontPath statements there for the X11 fonts), xorg.conf
(ditto), and gnome.
What puzzles me is why I see this on my Fedora Core 5 box (xorg based),
but not my RHEL 3 machine (XFree based). Perhaps in said difference
there is a clue.
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R | vnc | X11 fonts
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
Re: [Rd] R | vnc | X11 fonts
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 other gnome > windows manager is that twm uses X11 core fonts whereas gnome > is xft/fontconfig-aware, and as far as I know R's X11() uses > core font API's and is not xft-aware. > > You haven't said anything about your xorg setup - specifically, > whether you are using a font server (it is the default on FC5, so > unless you have changed it, you are using one). If that's the case, > changing this line in /etc/X11/xorg.conf > FontPath "unix/:7100" > to use *real* font paths may help. Thanks very much for the useful summary of some key points. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] compiling R | multi-Opteron | BLAS source
Thanks very much - I followed your advice, and have tried a variety of permutations (using ACML, and LAPACK). For the most part, I'm still 'playing' with multiple threads, but given the performance I'm getting (quad Opteron 880, 16 GB RAM, 64-bit FC5), I'll stick with that for now (but based on your examples, worth considering a single-thread build for comparisons - the svd test is pretty compelling). Here are some 'average values' from my machine for the benchmarks you posted: ACML3.5.0 - multi-threaded (compiled with gcc 4.0.1 and gfortran): system.time(for(i in 1:25) X%*%X) 11.75 0.335 3.900 0.000 0.000 system.time(for(i in 1:25) solve(X)) 22.410 2.621 13.481 0.000 0.000 system.time(for(i in 1:10) svd(X)) 67.384 4.28 38.585 0.000 0.000 Needless to say, on this level of system, most things run pretty fast - except the svd benchmark which lags, consistent with what you showed in your results. What is somewhat intriguing is why the svd example varies so much between (say) internal BLAS (165) and goto BLAS (for example; 43), for a single-thread compilation. But, it does look as if ACML is holding its own. Cheers... > The R-devel version of R provides a pluggable BLAS, which makes such tests > fairly easy (although building the BLAS themselves is not). On dual > Opterons, using multiple threads is often not worthwhile and can be > counter-productive (Doug Bates has found some dramatic examples, and you > can see them in my timings below). > > So timings for FC3, gcc 3.4.6, dual Opteron 252, 64-bit build of R. ACML > 3.5.0 is by far the easiest to install (on R-devel all you need to do is > to link libacml.so to lib/libRblas.so) and pretty competitive, so that is > what I normally use. > > These timings are not very repeatable: to a few % only even after > averaging quite a few runs. > > set.seed(123) > X <- matrix(rnorm(1e6), 1000) > system.time(for(i in 1:25) X%*%X) > system.time(for(i in 1:25) solve(X)) > system.time(for(i in 1:10) svd(X)) > > internal BLAS (-O3) > >> system.time(for(i in 1:25) X%*%X) >> > [1] 96.939 0.341 97.375 0.000 0.000 > >> system.time(for(i in 1:25) solve(X)) >> > [1] 110.316 1.652 112.006 0.000 0.000 > >> system.time(for(i in 1:10) svd(X)) >> > [1] 165.550 1.131 166.806 0.000 0.000 > > Goto 1.03, 1 thread > >> system.time(for(i in 1:25) X%*%X) >> > [1] 12.949 0.191 13.143 0.000 0.000 > >> system.time(for(i in 1:25) solve(X)) >> > [1] 23.201 1.449 24.652 0.000 0.000 > >> system.time(for(i in 1:10) svd(X)) >> > [1] 43.318 1.016 44.361 0.000 0.000 > > Goto 1.03, dual CPU > >> system.time(for(i in 1:25) X%*%X) >> > [1] 15.038 0.244 8.488 0.000 0.000 > >> system.time(for(i in 1:25) solve(X)) >> > [1] 26.569 2.239 19.814 0.000 0.000 > >> system.time(for(i in 1:10) svd(X)) >> > [1] 59.912 1.799 50.350 0.000 0.000 > > ACML 3.5.0 (single-threaded) > >> system.time(for(i in 1:25) X%*%X) >> > [1] 13.794 0.368 14.164 0.000 0.000 > >> system.time(for(i in 1:25) solve(X)) >> > [1] 22.990 1.695 24.710 0.000 0.000 > >> system.time(for(i in 1:10) svd(X)) >> > [1] 48.267 1.373 49.662 0.000 0.000 > > 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)) >> > [1] 50.150 1.462 51.619 0.000 0.000 > > ATLAS 3.6.0, multi-threaded > >> system.time(for(i in 1:25) X%*%X) >> > [1] 17.657 0.468 9.775 0.000 0.000 > >> system.time(for(i in 1:25) solve(X)) >> > [1] 38.388 2.353 30.141 0.000 0.000 > >> system.time(for(i in 1:10) svd(X)) >> > [1] 95.611 3.039 88.917 0.000 0.000 > > > On Sun, 23 Jul 2006, Evan Cooch wrote: > > >> 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 recently purchased a multi-Opteron system (bunch of >> 880 chips), running 64-bit RHEL 4 (which we have site licensed at our >> university, so it cost us nothing - good price) with SMP support built >> into the kernel (p
