On Fri, 14 May 2004, Li Long wrote: > Hi, R core developers, > > I work in the Swiss Institute of Bioinformatics. We have two clusters of > Intel Itanium2 clusters for bioinformaticians to crank their data. One > piece of software they use heavily is R and BioConductors. I ported the R > codes and R packages to this platform already, and am working on > optimizing their performance. I'm using Intel C/C++ compiler on this > platform running Linux. One of my findings is that turning some functions > in R to "inline" functions boost performance significantly. > > While R follows strict C89 standard right now, there're quite some good > reasons to relax the rule somewhat. From my experience in software > development in industry, I understand very well both the portability issue > and backward compatability issue, I also see the hidden cost of holding > back for too long and not fully achieving the potential of new technology,
Could you then please quantify that hidden cost? > I recommend that we allow "inline" functions in R's C codes. In what sense do `we' not allow it? And who is `we'? The problem is that very few compilers fully support C99, and others have different ways to indicate inlining. So a configure test is needed. I am sure that if you provide one together with patches to parts of the code where you find inlining beneficial, the real `we' would consider it carefully. Especially if the `hidden cost' is noticeable. .... > In R, there are quite some simple functions that are called extremely > often, such as "R_IsNaNorNA", "R_finite", etc. They are used in heavy > loops quite a lot. They disrupt the pipelining, and negatively affect the > performance of the software. For instance, on IA64, system call of > "isnan" cost 4 cycles, while a wrapper like "R_IsNaNorNA" could cost > several times more. However, one of the motivations of eliminating support for non-IEEE-754 platforms in R 2.0.0 is to enable some of this baggage to be eliminated. But the wrapper is there for a good reason: to get the right answer. Since I gather you have suitably modified code, it would be helpful to your case to provide data - on real problems - on a mainstream platform. of the actual performance impact of not inlining. -- 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, UK Fax: +44 1865 272595 ______________________________________________ [EMAIL PROTECTED] mailing list https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
