I am testing these against standard phylogenetics programs as they are my interest. Therefore, these benchmarks don’t speak to how well the processors work for games, conversion, compression, and other standard benchmark analyses.

I will have more detailed results up later, but testing against my own serial (non-parallel) program they are all about equivalent with the Nehalem chip being about 13% faster.

When testing again 3.1.2 MrBayes MPI version with 4 threads allowed on each machine, again, they are fairly equivalent. Differences are relatively negligible and similar to the non-parallel results.

However, when testing against the PTHREADS-SSE3 version of RAxML (7.2.2) I find large differences (again, allowing every machine to use 4 cores). If we use my home machine as the benchmark, it can do a particular analysis in 1200 seconds. The work computer with server chips runs the same dataset in about 900 seconds. This is probably due to cache issues and other things done better in server chips. The new Nehalem processors do the same dataset in 600 secs. So 1.5 times faster than the previous Xeon chips and twice as fast as the home computer! This is where the Nehalems shine, PTHREADS, or in other words, very tight parallelization.

Of course, they may shine in other types of analyses, but for phylogenetics software crunching numbers, this is where I have found the advantage.

Here are some basic specs:

• Processor: Intel Quad Core Q9550 2.83 Ghz (newegg)
• Motherboard: Gigabyte GA-EP45-UDR3 (newegg)
• RAM: 4 Gigs 1066 or 800 Mhz
• Video card: doesn’t really matter, but for linux compatibility NVIDIA
• Hard drive: 500GB Seagate
• DVD-R: doesn’t matter
• Case: doesn’t matter but I got an Antex 300

Whole thing is less than $700 and if you build it yourself you get a pretty great multicore analysis machine for pretty cheap.

Good stuff.

This follows a general trend in programming that started with FORTRAN way back in 50′s when engineers and scientists were thought to be more productive if they could just enter in the formulas directly instead of dealing with the programming specifics. Hence the name “The IBM Mathematical Formula Translating System”. Nevertheless, I am not sure many people in the biological sciences would consider FORTRAN very simple and obvious unless they already program.

What I wonder about here is the true merit of programming in a very high-level language? First, let’s just say C, C++, and Java, although they may be high-level as compared to assembly, they are lower level than Python, Perl and R. So, why chose Python, Perl, or R (or Matlab, or many of the other frameworks) over C, C++, and Java? Some reasons people give are: 1) easier to learn, 2) existing toolsets, 3) speed doesn’t matter, and 4) other languages are too hard.

First, let me say that I use both Python and R. I use R for some figure creation and statistics (though moving away for some of these for more flexibility). I use Python almost daily for text manipulation, dataset manipulation, simple tree manipulation, and for mocking up future programs. However, I do not favour it for programs meant for release.

Generally, the low level languages offer an enormous speed advantage over the higher level languages (see here). Also, despite the propaganda, they are easy to read and have an enormous following outside the biological sciences. Furthermore, they are generally truly cross platform and the tools are easily found for all operating systems.

Sure, it may take a little longer (few weeks) to start programming real programs with ease in C, C++, and Java, but speed matters. I know that there is the feeling that processors will get faster so it won’t matter, but also analyses will get harder. They already are. For example, a simple dataset in the biogeographic program lagrange takes 36 hours to complete (I have a real dataset in mind). An alpha c++ version of lagrange completes this dataset in 1 minute 30 seconds. These kinds of speed ups allow for endless complexity to be added to the program and procedure. Sure, if we wait for a fast processor, the 36 hours could shrink to 12 hours, or 6 hours, but how can you argue with a speed up of over 1000x.

Another issue is dataset size. There is the simple fact that R, python, and perl are less efficient with memory. For the same reason as above, for current datasets, this may not be a problem. However, datasets are growing and controling memory can be essential between completing an analysis and not completing one.

Because many of us are focusing on computational aspects of evolutionary biology, we can expect to build the best and most efficient tools. Just a thought, but those will probably be in C, C++, and Java.

It is great to see some of that dissertation get out there (a year later)!

“As a kid I was (and still am) heavily influenced by Carl Sagan, and a little later by Stephen Hawking. Now as I have started a family with two kids, currently age 5 and 2, I am wondering who out there is popularizing science. Currently, my wife and I can get the kids excited about the world around them, but I’d like to find someone inspiring from outside the family as they get older. Sure, we’ll always have ‘Cosmos,’ but are there any contemporaries who are trying to bring science into the public view in such a fun and intriguing way? Someone the kids can look up to and be inspired by? Where is the next Science Hero?”

Funny that Gould and Dawkins weren’t mentioned. Someone will have to step up it would seem. Carl Zimmer helps from the journalistic side, wonder who will follow from the scientific side.

Old age is a feature, not a bug. With less turn-over it would be difficult to life as a whole to adapt to changing environment.

The rest of the comment was a little wacky, but for a website comment I thought this was pretty insightful in relation to how generation time can influence evolution. Wonder if the 20/20 special will be that insightful.

Rapid and Accurate Large-Scale Coestimation of Sequence Alignments and Phylogenetic Trees

Kevin Liu,¹ Sindhu Raghavan,¹ Serita Nelesen,¹ C. Randal Linder,² Tandy Warnow^1,*

¹ Department of Computer Sciences, The University of Texas at Austin, One University Station C0500, Austin, TX 78712, USA.
² Section of Integrative Biology, School of Biological Sciences, The University of Texas at Austin, One University Station C0930, Austin, TX 78712, USA.

I am excited to give this stuff a try on my largest alignments and take a look at the differences.

(this is not an april fool’s posting despite the somewhat funny subject of IRC these days)

Since then however, I have not had the oppurtunity to do much development on the program because it is not directly related to my active research program. Most of the megaphylogeny development has moved to the program phlawd (I like self depricating names). I have started to feel like I am letting the user base down for phyutility. I still use the program almost everyday but find little time to extend or debug some of the issues because it is unrelated to any current research I am conducting.

I wonder how common this is in our field. The incentive to program beyond ones own research needs is lacking in the field. The expectation, however, is that programs are available and maintained in perpetuity. I would be happy to continue programming away on phyutility but until it comes back into the realm of my current research it is hard to devote the necessary time. I would find the time if there were ways to perhaps get summer support or other ways of suggesting to our institutions and the field that the maintenance of programs is important in its own right even if it is out of the current developer’s research (maybe grants for program maintenance for programs with particularly large user bases). For most of our programs the source code is available allowing for future development, perhaps by developers other than the original author. This doesn’t seem very common though.

Eh, maybe I am way off here. Just feeling bad that I can’t do more on phyutility right now.