Re: [Rd] FFT
On Fri, 7 Oct 2005, Jennifer Lai wrote: >Is FFT implemented in R takes advantage of multi-processors? > I ran this benchmark from from http://www.sciviews.org, and AMD Opteron > 2.2 GHz performs better than AMD Opteron 1.8 GHz on all test cases, > except FFT operation. > Both machines run same OSs (RedHat WS 3) and 2.2 GHz has more memory (2 > GB RAM) than 1.8 GHz (1 GB RAM). The only difference is that 1.8 GHz is > a dual-processor machine, and > 2.2 GHz is a single processor machine. Could this be the reason? > Does anyone has insights on this? I am pretty confident that nothing in Unix-alike R is multi-threaded. (The Windows port is.) However, you can use some multi-threaded addons, e.g. a BLAS library. AFAIK those chips differ in more than just speed, including exact cache details. Other details of the CPU architecture are often more important than small differences in clock speed. Even small compiler differences can affect performance a lot. I would also caution aginst drawing any conclusions at all from this sort of `benchmark' (indeed, would say it was a misuse of the term). Fortunately the computer world has moved on to using realistic tasks as comparators. When we last had a large procurement (a many-processor system fufilled by Opterons) we used real data-analysis programs written in C++ and Java. The tenders managed a very surprising difference in throughput on apparently identical CPUs, and results even from the same tender on different models of Opteron did not scale even approximately with clock speed. In the end we learnt more about the support skills of the potential suppliers than about the optimized performance of their systems. -- 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] svn version number
On 10/7/05, Duncan Murdoch <[EMAIL PROTECTED]> wrote:
> Gabor Grothendieck wrote:
> > On 10/7/05, Duncan Murdoch <[EMAIL PROTECTED]> wrote:
> >
> >>Gabor Grothendieck wrote:
> >>
> >>>Is there some way of automatically including the svn version number
> >>>of a package in the DESCRIPTION file or otherwise so that one
> >>>can check from within R which svn version number one has?
> >>
> >>You could do this by writing it into your Makefile, but there's no other
> >>existing support for it. I'd recommend combining the URL reported by
> >>"svn info" with the result of svnversion to get the most informative
> >>version. Watch out for cases of people who are trying to make your
> >>package from a tarfile, rather than an svn checkout. We have ended up
> >>with some fairly tricky Makefile programming to get what we want into
> >>the R banner.
> >
> >
> > There is no makefile at all currently as my package is all R. Also, I
> > currently use TortoiseSVN.
>
> Probably the simplest option is to set an svn:keywords property on one
> of your source files, and get Subversion to put the revision number into
> the source when you check out. This won't tell you if you've got a
> mixed or modified revision, but as long as you are careful not to do
> this, it might give you what you want.
>
> I've got no idea how to do this in TortoiseSVN (I use command line svn),
> but presumably the documentation will talk about it.
>
> Duncan Murdoch
>
Thanks. That seems to work. I created a file called VERSION
in the inst subdirectory with the single line:
$Id$
and added Id to that file's svn properties by right-clicking on
VERSION file in Windows Explorer, choosing Properties, click
on Subversion tab and enter the Id property. I then did a commit.
I was originally thinking of putting the version information in the
DESCRIPTION file since I think that that is where one would
normally look but am not too sure if there is a logical place for it
there so for the moment at least its in my VERSION file and one
can access it from R via:
file.show(system.file("VERSION", package = "mypkg"))
Question: Any other ideas of a good place to put this information?
The key requirement I have is that it should be accessible from
within R so that one can check that one is using the svn version
that one thinks one is using.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] windows/g95 peculiarity
I'm not looking for an answer here, this is just a report of a
peculiar event I've observed
and can reproduce.
I'm developing a g95 (20050129) compiled package on windows xp pro
using R-2.1.1, and gcc-3.4.2 (mingw special). An older version of the
F95 package compiled and ran without problems. The new version of the
package includes extensive changes in the code.
The package has a test function, rtest(), which sets up a testing
scenario and runs it.
If I try to immediately load the library after starting up R and
running rtest(), the following
occurs:
> library("bpkg")
.onLoad: running R_g95_init
> o = rtest()
Testing cm.estimate...
Using short data set (testing)...
25500.00 2499.000 11.0 300.
...
5 0.000
6 0.000
Operating system error: Not enough space
Memory allocation failed
(R exits in terminal, or freezes as GUI)
However, if I import a data element the rtest runs fine. I know
rtest() doesn't need the extra data import because it runs without
problems on our OS X version.
> library("bpkg")
.onLoad: running R_g95_init
> data(yij)
> o = rtest()
Testing cm.estimate...
Using short data set (testing)...
25500.00 2499.000 11.0 300.
...
6 0.000
Done
>
(R continues to run without problems)
The default rtest runs a short data set because the full test data set
takes about
30 seconds to compute. When I start off by running the full rtest data
set I also
don't have any problems with R.
This package runs without problems on a G4/Tiger OS X mac with R-2.1.1, although
we do compile it with gfortran on that platform.
This is just a report. If anyone has any questions let me know.
Best,
Joel
--
Joel Bremson
Graduate Student
Institute for Transportation Studies - UC Davis
http://etrans.blogspot.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] windows/g95 peculiarity
On Sat, 8 Oct 2005, Joel Bremson wrote:
> I'm not looking for an answer here, this is just a report of a
> peculiar event I've observed
> and can reproduce.
>
> I'm developing a g95 (20050129) compiled package on windows xp pro
> using R-2.1.1, and gcc-3.4.2 (mingw special). An older version of the
> F95 package compiled and ran without problems. The new version of the
> package includes extensive changes in the code.
>
> The package has a test function, rtest(), which sets up a testing
> scenario and runs it.
>
> If I try to immediately load the library after starting up R and
> running rtest(), the following
> occurs:
>
>> library("bpkg")
> .onLoad: running R_g95_init
>> o = rtest()
> Testing cm.estimate...
> Using short data set (testing)...
> 25500.00 2499.000 11.0 300.
> ...
> 5 0.000
> 6 0.000
> Operating system error: Not enough space
> Memory allocation failed
>
> (R exits in terminal, or freezes as GUI)
>
> However, if I import a data element the rtest runs fine. I know
> rtest() doesn't need the extra data import because it runs without
> problems on our OS X version.
I would guess your package (or something it is calling) is corrupting the
heap, or has another error in it. I'd suggest running under gdb and
identifying where the error message is coming from, and seeing at that
point what is causing it.
I have some instructions for debugging R packages in Windows on
http://www.stats.uwo.ca/faculty/murdoch/software/debuggingR/.
Duncan Murdoch
>
>> library("bpkg")
> .onLoad: running R_g95_init
>> data(yij)
>> o = rtest()
> Testing cm.estimate...
> Using short data set (testing)...
> 25500.00 2499.000 11.0 300.
> ...
> 6 0.000
> Done
>
>>
> (R continues to run without problems)
>
> The default rtest runs a short data set because the full test data set
> takes about
> 30 seconds to compute. When I start off by running the full rtest data
> set I also
> don't have any problems with R.
>
> This package runs without problems on a G4/Tiger OS X mac with R-2.1.1,
> although
> we do compile it with gfortran on that platform.
>
> This is just a report. If anyone has any questions let me know.
>
> Best,
>
> Joel
>
> --
> Joel Bremson
> Graduate Student
> Institute for Transportation Studies - UC Davis
> http://etrans.blogspot.com
>
> __
> 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
