[Rd] Sys.sleep waits forever + workaround (PR#8678)
When I tried to schedule a calculation for the next day (waiting several
1 seconds), I noticed that Sys.sleep does never return (R version
2.1.0 on Linux). From the C code I expect that the maximum number of
seconds is about 2000 (2^31/1e6), which is system-dependent.
##Sys.sleep <- function(time)
##invisible(.Internal(Sys.sleep(time)))
Sys.sleep <- function(time) {
nloops <- time%/%1000
while (nloops>0) {
nloops <- nloops-1
.Internal(Sys.sleep(1000))
}
invisible(.Internal(Sys.sleep(time%%1000)))
}
--
Andreas Westfeld, 0432 01CC F511 9E2B 0B57 5993 0B22 98F8 4AD8 EEEA
<[EMAIL PROTECTED]> http://www.inf.tu-dresden.de/~aw4
TU Dresden Fakultät Informatik, Institut für Systemarchitektur
Datenschutz und Datensicherheit, Tel. +49-351-463-37918
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Sys.sleep waits forever + workaround (PR#8678)
On Mon, 13 Mar 2006, [EMAIL PROTECTED] wrote:
> When I tried to schedule a calculation for the next day (waiting several
> 1 seconds), I noticed that Sys.sleep does never return (R version
> 2.1.0 on Linux). From the C code I expect that the maximum number of
> seconds is about 2000 (2^31/1e6), which is system-dependent.
Actually, it is not: is always (2^31-1)/1e6.
This is easy to fix at C level, and I have done so.
>
> ##Sys.sleep <- function(time)
> ##invisible(.Internal(Sys.sleep(time)))
>
> Sys.sleep <- function(time) {
>nloops <- time%/%1000
>while (nloops>0) {
>nloops <- nloops-1
>.Internal(Sys.sleep(1000))
>}
>invisible(.Internal(Sys.sleep(time%%1000)))
> }
>
>
>
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Building help pages
Hello! I was just wondering, why only one of my "Rd" files is converted in "chm" format (REGE) and the other are not when installing a package? The output from installing a package on WinXp is below. I tried to find more information about what "chm" format actually is, however have found none. Best regards and thaks for any replies, Ales Ziberna C:\Ales\Statistika>R CMD INSTALL blockmodeling -- Making package blockmodeling adding build stamp to DESCRIPTION installing NAMESPACE file and metadata making DLL ... ... DLL made installing DLL installing R files installing man source files installing indices installing help >>> Building/Updating help pages for package 'blockmodeling' Formats: text html latex example chm Pajek texthtmllatex REGE texthtmllatex example chm check.these.par texthtmllatex example clu texthtmllatex example crit.fun texthtmllatex example find.mtexthtmllatex formatA texthtmllatex example fun.by.blocks texthtmllatex example gplot1texthtmllatex nkpartitions texthtmllatex example opt.par texthtmllatex example opt.random.partexthtmllatex example plot.mat texthtmllatex example rand texthtmllatex recodetexthtmllatex example sedisttexthtmllatex example sstexthtmllatex two2one texthtmllatex example Microsoft HTML Help Compiler 4.74.8702 Compiling c:\Ales\Statistika\blockmodeling\chm\blockmodeling.chm Compile time: 0 minutes, 3 seconds 19 Topics 144 Local links 7 Internet links 1 Graphic Created c:\Ales\Statistika\blockmodeling\chm\blockmodeling.chm, 59,385 bytes Compression decreased file by 44,606 bytes. preparing package blockmodeling for lazy loading adding MD5 sums __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Building help pages
Aleš Žiberna wrote: > Hello! > > I was just wondering, why only one of my "Rd" files is converted in > "chm" format (REGE) and the other are not when installing a package? The > output from installing a package on WinXp is below. I guess your are installing from a source directory from which you already have installed some time ago. The chm files correpsonding to *unchanged* Rd files are not re-generated. So In guess only REGE.Rd has changed in the meantime. > I tried to find more information about what "chm" format actually is, > however have found none. Microsoft's compiled html format can be accessed by, e.g. options(chmhelp=TRUE) ?plot Uwe Ligges > Best regards and thaks for any replies, > Ales Ziberna > > > C:\Ales\Statistika>R CMD INSTALL blockmodeling > > > -- Making package blockmodeling > adding build stamp to DESCRIPTION > installing NAMESPACE file and metadata > making DLL ... > ... DLL made > installing DLL > installing R files > installing man source files > installing indices > installing help > >>> Building/Updating help pages for package 'blockmodeling' > Formats: text html latex example chm > Pajek texthtmllatex > REGE texthtmllatex example chm > check.these.par texthtmllatex example > clu texthtmllatex example > crit.fun texthtmllatex example > find.mtexthtmllatex > formatA texthtmllatex example > fun.by.blocks texthtmllatex example > gplot1texthtmllatex > nkpartitions texthtmllatex example > opt.par texthtmllatex example > opt.random.partexthtmllatex example > plot.mat texthtmllatex example > rand texthtmllatex > recodetexthtmllatex example > sedisttexthtmllatex example > sstexthtmllatex > two2one texthtmllatex example > Microsoft HTML Help Compiler 4.74.8702 > > Compiling c:\Ales\Statistika\blockmodeling\chm\blockmodeling.chm > > > Compile time: 0 minutes, 3 seconds > 19 Topics > 144 Local links > 7 Internet links > 1 Graphic > > > Created c:\Ales\Statistika\blockmodeling\chm\blockmodeling.chm, 59,385 bytes > Compression decreased file by 44,606 bytes. > preparing package blockmodeling for lazy loading > adding MD5 sums > > __ > 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
Re: [Rd] Building help pages
Thank you for this clarification. You are off course right, this was the only "Rd" file that was changed. Best regards, Ales Ziberna Uwe Ligges pravi: > Aleš Žiberna wrote: > >> Hello! >> >> I was just wondering, why only one of my "Rd" files is converted in >> "chm" format (REGE) and the other are not when installing a package? >> The output from installing a package on WinXp is below. > > I guess your are installing from a source directory from which you > already have installed some time ago. The chm files correpsonding to > *unchanged* Rd files are not re-generated. So In guess only REGE.Rd > has changed in the meantime. > > >> I tried to find more information about what "chm" format actually is, >> however have found none. > > Microsoft's compiled html format can be accessed by, e.g. > options(chmhelp=TRUE) > ?plot > > Uwe Ligges > > >> Best regards and thaks for any replies, >> Ales Ziberna >> >> >> C:\Ales\Statistika>R CMD INSTALL blockmodeling >> >> >> -- Making package blockmodeling >> adding build stamp to DESCRIPTION >> installing NAMESPACE file and metadata >> making DLL ... >> ... DLL made >> installing DLL >> installing R files >> installing man source files >> installing indices >> installing help >> >>> Building/Updating help pages for package 'blockmodeling' >> Formats: text html latex example chm >> Pajek texthtmllatex >> REGE texthtmllatex example chm >> check.these.par texthtmllatex example >> clu texthtmllatex example >> crit.fun texthtmllatex example >> find.mtexthtmllatex >> formatA texthtmllatex example >> fun.by.blocks texthtmllatex example >> gplot1texthtmllatex >> nkpartitions texthtmllatex example >> opt.par texthtmllatex example >> opt.random.partexthtmllatex example >> plot.mat texthtmllatex example >> rand texthtmllatex >> recodetexthtmllatex example >> sedisttexthtmllatex example >> sstexthtmllatex >> two2one texthtmllatex example >> Microsoft HTML Help Compiler 4.74.8702 >> >> Compiling c:\Ales\Statistika\blockmodeling\chm\blockmodeling.chm >> >> >> Compile time: 0 minutes, 3 seconds >> 19 Topics >> 144 Local links >> 7 Internet links >> 1 Graphic >> >> >> Created c:\Ales\Statistika\blockmodeling\chm\blockmodeling.chm, >> 59,385 bytes >> Compression decreased file by 44,606 bytes. >> preparing package blockmodeling for lazy loading >> adding MD5 sums >> >> __ >> 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
Re: [Rd] problem building R-patched on x86-64 with PGI 6.1
Prof Brian Ripley wrote: > >> As those of you who saw my post on R-help know, I've been trying to >> build >> R-patched on a dual Opteron box running Scyld Beowulf, using the PGI 6.1 >> compilers. The build went fine, but I couldn't get it to pass make >> check-all. Jennifer Lai, who reported success with PGI 6.0 previously, >> seems to have the same problem with 6.1. Here are the particulars: >> >> Since R requires IEEE754 conformance, the flag to use for PGI is -Kieee. >> (BTW, configure still insist on sticking in -mieee-fp, which generates a >> warning.) With that flag, the build runs into trouble with the first >> example in ?optim. Running it by hand gives me: > > > Well, configure insists on doing so because we were told it was correct. > (Will change.) Is -Kieee always correct for PG? > Looking at > > http://www.amd.com/us-en/assets/content_type/DownloadableAssets/dwamd_PGI_nov603.pdf > > > > suggests you might want to try -pc64 -Kieee. > Thanks, Prof. Ripley! The optim example pass the sanity check with -pc64 -Kieee flag. "make check" now fails at reg-tests-1.R Regards, Jennifer __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] dotchart: Gap between text and chart (PR#8681)
(Moved from r-help)
On 3/13/2006 9:33 AM, Dietrich Trenkler wrote:
> I have some data which I would like to display with dotchart. The
> labels are very long, so the chart becomes too small. Setting cex=0.7
> seems to be a good compromise, but the gap between the text and the
> chart still is too large. I did not find a "gap" parameter in the
> description of dotchart...
>
> Thanks for any help.
>
> D. Trenkler
>
>
> "a" <- structure(c(103.35, 36.73, 55.09, 302.66, 68.54, 35.46,
> 138.65, 25.21, 110.85, 6.66, 46.57, 70.23), .Names =
> c("Nahrungsmittel und alkoholfreie Getraenke",
> "Alkoholische Getraenke, Tabakwaren", "Bekleidung und Schuhe",
> "Wohnungsmieten, Energie", "Einrichtungsgegenstaende",
> "Gesundheitspflege",
> "Verkehr", "Nachrichtenuebermittlung", "Freizeit, Unterhaltung und
> Kultur",
> "Bildungswesen", "Beherbergungs und Gaststaettendienstleistungen",
> "Andere Waren und Dienstleistungen"))
>
> dotchart(sort(a))
> dotchart(sort(a),cex=0.7)
I've determined that this is a bug in dotchart. It miscalculates the
height of a line of text in the right margin, using
lheight <- strheight("M", "inch")
which doesn't give the right answer. You get the correct answer in this
case by putting
lheight <- par("mai")[2]/par("mar")[2]
but that's not a general solution, as the denominator may be zero.
I'll look for a better solution.
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] dotchart: Gap between text and chart (PR#8681)
On Mon, 13 Mar 2006, [EMAIL PROTECTED] wrote:
> (Moved from r-help)
>
> On 3/13/2006 9:33 AM, Dietrich Trenkler wrote:
>> I have some data which I would like to display with dotchart. The
>> labels are very long, so the chart becomes too small. Setting cex=0.7
>> seems to be a good compromise, but the gap between the text and the
>> chart still is too large. I did not find a "gap" parameter in the
>> description of dotchart...
>>
>> Thanks for any help.
>>
>> D. Trenkler
>>
>>
>> "a" <- structure(c(103.35, 36.73, 55.09, 302.66, 68.54, 35.46,
>> 138.65, 25.21, 110.85, 6.66, 46.57, 70.23), .Names =
>> c("Nahrungsmittel und alkoholfreie Getraenke",
>> "Alkoholische Getraenke, Tabakwaren", "Bekleidung und Schuhe",
>> "Wohnungsmieten, Energie", "Einrichtungsgegenstaende",
>> "Gesundheitspflege",
>> "Verkehr", "Nachrichtenuebermittlung", "Freizeit, Unterhaltung und
>> Kultur",
>> "Bildungswesen", "Beherbergungs und Gaststaettendienstleistungen",
>> "Andere Waren und Dienstleistungen"))
>>
>> dotchart(sort(a))
>> dotchart(sort(a),cex=0.7)
>
> I've determined that this is a bug in dotchart. It miscalculates the
> height of a line of text in the right margin, using
>
> lheight <- strheight("M", "inch")
>
> which doesn't give the right answer. You get the correct answer in this
> case by putting
>
> lheight <- par("mai")[2]/par("mar")[2]
>
> but that's not a general solution, as the denominator may be zero.
>
> I'll look for a better solution.
Like setting mai not mar? The ratio is par("csi"), by the way.
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] problem building R-patched on x86-64 with PGI 6.1
Jennifer Lai wrote: > Prof Brian Ripley wrote: > >> >>> As those of you who saw my post on R-help know, I've been trying to >>> build >>> R-patched on a dual Opteron box running Scyld Beowulf, using the PGI >>> 6.1 >>> compilers. The build went fine, but I couldn't get it to pass make >>> check-all. Jennifer Lai, who reported success with PGI 6.0 previously, >>> seems to have the same problem with 6.1. Here are the particulars: >>> >>> Since R requires IEEE754 conformance, the flag to use for PGI is >>> -Kieee. >>> (BTW, configure still insist on sticking in -mieee-fp, which >>> generates a >>> warning.) With that flag, the build runs into trouble with the first >>> example in ?optim. Running it by hand gives me: >> >> >> >> Well, configure insists on doing so because we were told it was correct. >> (Will change.) Is -Kieee always correct for PG? >> Looking at >> >> http://www.amd.com/us-en/assets/content_type/DownloadableAssets/dwamd_PGI_nov603.pdf >> >> >> >> suggests you might want to try -pc64 -Kieee. >> > Thanks, Prof. Ripley! The optim example pass the sanity check with > -pc64 -Kieee flag. > "make check" now fails at reg-tests-1.R > > Actually the -pc64 didn't help. I forgot that at some point my environment was configured to pick up PGI 6.0 compiler instead of PGI 6.1 (for testing purpose). The optim example compiled with PGI 6.0, but not PGI 6.1. Sorry for the confusion. - Jennifer __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] dotchart: Gap between text and chart (PR#8681)
On 3/13/2006 12:55 PM, Prof Brian Ripley wrote:
> On Mon, 13 Mar 2006, [EMAIL PROTECTED] wrote:
>
>> (Moved from r-help)
>>
>> On 3/13/2006 9:33 AM, Dietrich Trenkler wrote:
>>> I have some data which I would like to display with dotchart. The
>>> labels are very long, so the chart becomes too small. Setting cex=0.7
>>> seems to be a good compromise, but the gap between the text and the
>>> chart still is too large. I did not find a "gap" parameter in the
>>> description of dotchart...
>>>
>>> Thanks for any help.
>>>
>>> D. Trenkler
>>>
>>>
>>> "a" <- structure(c(103.35, 36.73, 55.09, 302.66, 68.54, 35.46,
>>> 138.65, 25.21, 110.85, 6.66, 46.57, 70.23), .Names =
>>> c("Nahrungsmittel und alkoholfreie Getraenke",
>>> "Alkoholische Getraenke, Tabakwaren", "Bekleidung und Schuhe",
>>> "Wohnungsmieten, Energie", "Einrichtungsgegenstaende",
>>> "Gesundheitspflege",
>>> "Verkehr", "Nachrichtenuebermittlung", "Freizeit, Unterhaltung und
>>> Kultur",
>>> "Bildungswesen", "Beherbergungs und Gaststaettendienstleistungen",
>>> "Andere Waren und Dienstleistungen"))
>>>
>>> dotchart(sort(a))
>>> dotchart(sort(a),cex=0.7)
>>
>> I've determined that this is a bug in dotchart. It miscalculates the
>> height of a line of text in the right margin, using
>>
>> lheight <- strheight("M", "inch")
>>
>> which doesn't give the right answer. You get the correct answer in this
>> case by putting
>>
>> lheight <- par("mai")[2]/par("mar")[2]
>>
>> but that's not a general solution, as the denominator may be zero.
>>
>> I'll look for a better solution.
>
> Like setting mai not mar? The ratio is par("csi"), by the way.
Yes, setting mai rather than mar simplifies the code a bit, but some
parts still need to work in lines, because mtext doesn't accept
positioning arguments in inches. I've used par("csi") in place of the
ratio now, and am about to commit to r-devel and r-patched.
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Help on interfacing C++ with R
Hi, I am trying to set up a C++ library for my R code. I followed the
R-extension manual but found out that the example of "X.cpp, X_main.cpp"
is somewhat too simple. Here is my code:
//lib4R.h testing for interfacing C++ with R -- using C++ library in R
#include
using namespace std;
class lib4R {
public:
lib4R();
~lib4R();
int testIntDivision(int, int);
double testDoubleMultiplication(double, double);
int getID();
void setID(int);
private:
int ID;
};
// lib4R.cpp : Defines the entry points for the library.
#include "lib4R.h"
lib4R::lib4R() {
cout << "Constructor lib4R()" << endl;
}
lib4R::~lib4R() {
cout << "Destructor ~lib4R()" << endl;
}
extern "C" {
int lib4R::testIntDivision(int a, int b) {
return a/b;
}
double lib4R::testDoubleMultiplication(double a, double b) {
return a*b;
}
int lib4R::getID() {
return this->ID;
}
void lib4R::setID(int ID) {
this->ID = ID;
}
int main(int argc, char* argv[])
{
cout << "Entering main()" << endl;
lib4R lib1;
cout << "testIntDivision(4,2) = " << lib1.testIntDivision(4,2) <<
endl;
return 0;
}
} // extern C
I am working on Windows. I use these to compile the dll with Visual C++:
cl /MT /c lib4R.cpp
link /dll /out:lib4R.dll /export:testIntDivision /export:main lib4R.obj
So when I start rterm.exe:
>dyn.load("../lib4R.dll");
>.C("main");
Entering main()
Constructor lib4R()
testIntDivision(4,2) = 2
Destructor ~lib4$()
list()
The output is correct, but if I
>.C("testIntDivision", 4, 2);
it generated the dialog box claiming "R has encountered a problem and
needs to be closed...Please tell Microsoft about this problem",
sigh.
So what's wrong with my code, how do I use individual methods/functions of
C++ in R?
Thanks in advance for any help you can offer!
Bing
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Help on interfacing C++ with R
On Mon, 13 Mar 2006 [EMAIL PROTECTED] wrote:
> Hi, I am trying to set up a C++ library for my R code. I followed the
> R-extension manual but found out that the example of "X.cpp, X_main.cpp"
> is somewhat too simple. Here is my code:
Simpler is easier, all this std stuff gets in the way. The problem is that
R is passing pointers (probably) to doubles, not simple integers. As far
as I can see, you need to change the
.C("testIntDivision", 4, 2);
to make sure your numbers are integers (as.integer()) is OK), and the
function itself (provided that it is visible, and I've no idea if this is
the case, to pointer arguments:
int testIntDivision(int&, int&); // untried
then pick out the integer values at those addresses. It'll be one or both
of these problems (I am not fluent in C++, but the same principles apply
to C).
I would be concerned about exporting any competing main to load
dynamically into R too, could you compile the code in two files, one the
code to load into R, the other with main calling your code, and *only*
load what needs to be inside R?
>
> //lib4R.h testing for interfacing C++ with R -- using C++ library in R
> #include
> using namespace std;
>
> class lib4R {
> public:
> lib4R();
> ~lib4R();
>
> int testIntDivision(int, int);
> double testDoubleMultiplication(double, double);
>
> int getID();
> void setID(int);
> private:
> int ID;
> };
>
> // lib4R.cpp : Defines the entry points for the library.
> #include "lib4R.h"
>
> lib4R::lib4R() {
> cout << "Constructor lib4R()" << endl;
> }
>
> lib4R::~lib4R() {
> cout << "Destructor ~lib4R()" << endl;
> }
>
> extern "C" {
>
> int lib4R::testIntDivision(int a, int b) {
> return a/b;
> }
>
> double lib4R::testDoubleMultiplication(double a, double b) {
> return a*b;
> }
>
> int lib4R::getID() {
> return this->ID;
> }
>
> void lib4R::setID(int ID) {
> this->ID = ID;
> }
>
> int main(int argc, char* argv[])
> {
> cout << "Entering main()" << endl;
> lib4R lib1;
>
> cout << "testIntDivision(4,2) = " << lib1.testIntDivision(4,2) <<
> endl;
>
> return 0;
> }
>
> } // extern C
>
> I am working on Windows. I use these to compile the dll with Visual C++:
>
> cl /MT /c lib4R.cpp
> link /dll /out:lib4R.dll /export:testIntDivision /export:main lib4R.obj
>
> So when I start rterm.exe:
>
> >dyn.load("../lib4R.dll");
> >.C("main");
> Entering main()
> Constructor lib4R()
> testIntDivision(4,2) = 2
> Destructor ~lib4$()
> list()
>
> The output is correct, but if I
> >.C("testIntDivision", 4, 2);
>
> it generated the dialog box claiming "R has encountered a problem and
> needs to be closed...Please tell Microsoft about this problem",
> sigh.
>
> So what's wrong with my code, how do I use individual methods/functions of
> C++ in R?
>
> Thanks in advance for any help you can offer!
>
> Bing
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
Roger Bivand
Economic Geography Section, Department of Economics, Norwegian School of
Economics and Business Administration, Helleveien 30, N-5045 Bergen,
Norway. voice: +47 55 95 93 55; fax +47 55 95 95 43
e-mail: [EMAIL PROTECTED]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Peculiar timing result
On 3/11/06, Prof Brian Ripley <[EMAIL PROTECTED]> wrote: > Here is a summary of some results on a dual Opteron 252 running FC3 > > 64-bit gcc 3.4.5 > R's blas34.83 3.45 38.56 > ATLAS 36.70 3.28 40.14 > ATLAS multithread 76.85 5.39 82.29 > Goto 1 thread 36.17 3.44 39.76 > Goto multithread 178.06 345.97 467.99 > ACML49.69 3.36 53.23 > > 64-bit gcc 4.1.0 > R's blas34.98 3.49 38.55 > 32-bit gcc 3.4.5 > R's blas33.72 3.27 36.99 > 32-bit gcc 4.1.0 > R's blas34.62 3.25 37.93 > > The timings are not that repeatable, but the message seems clear that > this problem does not benefit from a tuned BLAS and the overhead from > multiple threads is harmful. (The gcc 4.1.0 results took fewer > iterations, which skews the results in its favour.) > > And my 2GHz Pentium M laptop under Windows gave 39.96 3.68 44.06. > > Clearly the Goto BLAS has a problem here: the results are slower on a dual > 252 than a dual 248 (see below). Thanks for the information on the timings. It happens that this message ended up in my R-help folder and I only got around to reading that folder today. Is it ok with you if I forward this message to Simon Urbanek? I am having similar difficulties in the timing with R on a dual-core Intel MacBook. > > > On Fri, 3 Mar 2006, Prof Brian Ripley wrote: > > > On Fri, 3 Mar 2006, Douglas Bates wrote: > > > >> I have been timing a particular model fit using lmer on several > >> different computers and came up with a peculiar result - the model fit > >> is considerably slower on a dual-core Athlon 64 using Goto's > >> multithreaded BLAS than on a single-core processor. > > > > Is there a Goto BLAS tuned for that chip? I can only see one tuned for an > > (unspecified) Opteron. L1 and L2 cache sizes do sometimes matter a lot > > for tuned BLAS, and (according to the AMD site I just looked up) the X2 > > 3800+ only has a 512Kb per core L2 cache. Opterons have a 1Mb L2 cache. > > > > Also, the very large system time seen in the dual-core run is typical of > > what I see when pthreads is not working right, and I suggest you try a > > limit of one thread (see the R-admin manual). On our dual-processor > > Opteron 248 that ran in 44 secs instead of 328. > > > >> Here is the timing on a single-core Athlon 64 3000+ running under > >> today's R-devel with version 0.995-5 of the Matrix package. > >> > >>> library(Matrix) > >>> data(star, package = 'mlmRev') > >>> system.time(fm1 <- lmer(math~gr+sx+eth+cltype+(yrs|id)+(1|tch)+(yrs|sch), > >>> star, > > control = list(nit=0,grad=0,msV=1))) > >> [1] 43.10 3.78 48.41 0.00 0.00 > >> > >> > >> (If you run the timing yourself and don't want to see the iteration > >> output, take the msV=1 out of the control list. I keep it in there so > >> I can monitor the progress.) > >> > >> If I time the same model fit on a dual-core Athlon 64 X2 3800+ with > >> the same version of R, BLAS and Matrix package, the timing ends up > >> with something like > >> > >> 90 140 235 0 0 > > > > > > > > -- > Brian D. Ripley, [EMAIL PROTECTED] > Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ > University of Oxford, Tel: +44 1865 272861 (self) > 1 South Parks Road, +44 1865 272866 (PA) > Oxford OX1 3TG, UKFax: +44 1865 272595 > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] problem building R-patched on x86-64 with PGI 6.1
Thanks to Brian, I can now get PGI 6.1 to build R-devel (2006-03-13 r37533) and pass make check-all, using the config flags I showed in my original post. I will try to re-build with optimizing flags, and report back if I run into problems there. Best, Andy From: Jennifer Lai > > Jennifer Lai wrote: > > > Prof Brian Ripley wrote: > > > >> > >>> As those of you who saw my post on R-help know, I've been > trying to > >>> build > >>> R-patched on a dual Opteron box running Scyld Beowulf, > using the PGI > >>> 6.1 > >>> compilers. The build went fine, but I couldn't get it to > pass make > >>> check-all. Jennifer Lai, who reported success with PGI > 6.0 previously, > >>> seems to have the same problem with 6.1. Here are the > particulars: > >>> > >>> Since R requires IEEE754 conformance, the flag to use for PGI is > >>> -Kieee. > >>> (BTW, configure still insist on sticking in -mieee-fp, which > >>> generates a > >>> warning.) With that flag, the build runs into trouble > with the first > >>> example in ?optim. Running it by hand gives me: > >> > >> > >> > >> Well, configure insists on doing so because we were told it was > >> correct. (Will change.) Is -Kieee always correct for PG? > Looking at > >> > >> > http://www.amd.com/us-en/assets/content_type/DownloadableAssets/dwamd > >> _PGI_nov603.pdf > >> > >> > >> suggests you might want to try -pc64 -Kieee. > >> > > Thanks, Prof. Ripley! The optim example pass the sanity check with > > -pc64 -Kieee flag. > > "make check" now fails at reg-tests-1.R > > > > > Actually the -pc64 didn't help. I forgot that at some point my > environment was configured to pick up PGI 6.0 compiler instead of PGI > 6.1 (for testing purpose). > The optim example compiled with PGI 6.0, but not PGI 6.1. > > Sorry for the confusion. > > - Jennifer > > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
