Posted by
dscho on
URL: http://imagej.273.s1.nabble.com/Computer-specifications-for-Fiji-ImageJ-tp5001644p5001651.html
Hi Zach,
On Fri, 1 Feb 2013, Zach Freyberg wrote:
> I am in the process of building a relatively high-powered computer imaging
> workstation for processing microscope-acquired images. I plan on doing a lot
> of fast time-scale image acquisition which will result in image stacks of
> >9,000 images per stack. I also plan on using the computer for creating 3-D
> reconstructions/movies of some of these images. To handle these demands, I
> had originally planned on building a computer including:
> 64GB, DDR3 RDIMM Memory, 1600MHz, ECC (8 x 8GB DIMMs)
> Dual Six Core XEON E5-2630, 2.3GHz, 15M, 7.2 GT/s,Turbo
> 2.5GB NVIDIAR Quadro 5000 graphics card
> Windows 7, 64-bit
>
> Based on reading a recent thread, my first question is whether Fiji and/or
> Image J will run normally on a set up like this, particularly with a dual
> processor setup and >32GB RAM? Secondly, does it make sense to get a single
> processor running faster with fewer threads (i.e. a single 8 core Xeon
> processor with 3.1GHz, 20M, 8.0 GT/s)? Any insights would be greatly
> appreciated!
I worked with a 16 core machine that has 128GB installed for a couple of
years. It works fine with Fiji (and therefore ImageJ).
My personal impression was that machines with more RAM run smoother with
Linux than with Windows. I did not perform statistics on that, so please
take that with a big grain of salt.
As Gabriel pointed out, the crucial point is to have multi-threaded
software (i.e. if you want to write plugins yourself, you need to make
sure that the code uses the ExecutorService, for primitive PlugInFilters,
using the PARALLELIZE_STACKS flag might be enough, in general you really
need to use a more sophisticated approach, e.g. by using ImgLib2).
As to the question whether to pick one CPU with more cores or two CPUs
with less: the details depend very much on your mainboard, but as a rule
of thumb: keeping the cores within the same CPU makes things faster, as
there are multiple levels of caching, and the fastest is always inside the
CPU (typically, more than one level, even).
As to video adapters: despite their policies, NVidia seems to be still the
top notch, although I hear that OpenCL is getting there (NVidia cultivated
the idea that you could use video adapters for massively parallel
computation rather than just rendering; they established the CUDA library
for that -- which required NVidia, naturally -- and OpenCL was designed as
a adapter-independent way to use video adapters for computation).
But again, to use NVidia properly, you have to write your software using
CUDA.
If you want to use the video adapter purely for 3D rendering, the most
important point is: how much RAM does the video adapter have.
Ciao,
Johannes
--
ImageJ mailing list:
http://imagej.nih.gov/ij/list.html