[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [igraph] R versus Python

From: address@hidden
Subject: Re: [igraph] R versus Python
Date: Sat, 3 Dec 2011 09:47:17 +0100


I would like to add, that since R 2.14.0 there is default compiler which vectorizes loops.
You can also load it with library(compiler) and use cmpfun(..) to compile to byte code your function.
Consider also using OpenBlas or recompiled Atlas library if You do matrix computations. Moreover, if You work with matrices that are sparse there are also tools in R. But for crossproduct use crossproduct(x,x) and not t(x)%*%x and have a look at Matrix package which provides many optimized functions.
Check for comparison Comparing Least Squares Calculations. Douglas Bates

Also you should avoid loops using by(..), lapply(..), do.call(..) and friends... it's easy with proper coding.

Best regards,

On 2 December 2011 23:10, Tamás Nepusz <address@hidden> wrote:
> Seems like Python might not object to nested for, plus it has the igraph routines available.
> Anyone got any advice?
Just my two cents:

A "for" loop in an interpreted language (like R, Python, Ruby or anything like that) will never be as fast as a "for" loop in plain C, period. Python might be a bit better in looping than R, but I don't expect the difference to be very significant. Even in Python, efficient numeric computations usually rely on NumPy, which pulls the same vectorization trick to do things efficiently as R or Matlab does. The same trick is done in Python when one translates a "for loop" into a list comprehension: the looping in the list comprehension is done in the C layer, thus it is much faster than the equivalent for loop. However, since not all for loops can be converted into list comprehensions, there are cases where one simply cannot avoid using loops. I guess the same applies for R.

Depending on the task you are trying to achieve, it might be the case that it is not the "for" loop that is the bottleneck in your program but something else. My opinion is that since you are already familiar with the R interface (definitely more than with the Python interface), it might be better to profile your R code to see where the bottlenecks are. I don't know how profiling works exactly in R, but once you have identified which call(s) or loop(s) are taking the most amount of time, you will at least know where to focus your efforts on.

If your code is concise, you can also try posting it here in case some of the R experts on this list (not me :)) are able to spot some obvious opportunities for speedups.


igraph-help mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]