Re: Books and other things which cost money to improve performance

Matthias-Christian Ott <ott@mirix.org>
Sat, 10 Jul 2010 12:38:57 +0200

          From comp.compilers

Related articles
Books and other things which cost money to improve performance Colin_Paul_Gloster@ACM.org (Colin Paul Gloster) (2010-07-05)
Re: Books and other things which cost money to improve performance DrDiettrich1@aol.com (Hans-Peter Diettrich) (2010-07-06)
Re: Books and other things which cost money to improve performance gneuner2@comcast.net (George Neuner) (2010-07-06)
Re: Books and other things which cost money to improve performance Colin_Paul_Gloster@ACM.org (Paul Colin Gloster) (2010-07-09)
Re: Books and other things which cost money to improve performance ott@mirix.org (Matthias-Christian Ott) (2010-07-10)
Re: Books and other things which cost money to improve performance gneuner2@comcast.net (George Neuner) (2010-07-11)
Re: Books and other things which cost money to improve performance Colin_Paul_Gloster@ACM.org (Paul Colin Gloster) (2010-08-31)
| List of all articles for this month |
From: Matthias-Christian Ott <ott@mirix.org>
Newsgroups: comp.compilers
Date: Sat, 10 Jul 2010 12:38:57 +0200
Organization: Compilers Central
References: 10-07-009 10-07-011
Keywords: optimize
Posted-Date: 10 Jul 2010 07:33:22 EDT

On Fri, Jul 09, 2010 at 10:05:30AM -0400, Paul Colin Gloster wrote:
[...]
> As for changing the number of cores: earlier this week I did try
> switching from a single core to four cores. (I did this merely by
> adding G.C.C.'s -ftree-parallelize-loops=4 switch because I am not
> ready to tackle the code for it (and I might never bother because I
> have many things to do which would have definitely positive results)
> and because the same urgent budgetary deadline which rushed the list
> of books at the start of this thread was also rushing me to determine
> whether we should buy FPGAs from XtremeData.) It was much slower and
> used basically just one core. The pseudoFORTRAN version supposedly did
> run on a GNU/Linux cluster, so if true, then it may be possible to
> exploit more than one Intel core or an FPGA or a GPU, but maybe not
> now. So I doubt that I will be recommending to order big FPGAs next
> week.
>
> (I think I might recommend that we still buy a cheap PCI or PCIe FPGA
> next week, if the thousands of Euro on software; probably more than
> a thousand Euro on books; and whatever I might recommend for
> consultants (I am not sure whether consultants are covered by one of
> the current budgets) do not exhaust these budgets.)


Some people at the Bioinformatics Department in my university use
GPGPU (they use CUDA with Mathlab) for their lightweight number
crunching. I think GPGPU should be cheaper, because graphics cards are
commodities these days, but FPGAs (especially development boards)
still aren't. Moreover, there are mainboards with 4-Way SLI and
graphics cards with 2 GPUs on them.


You may also want to give parallelisation APIs like OpenMP or Intel
TBB a try.


In general I find it hard to have a performance model for an x86
processor, because there are so many of them which share the same
instruction set, but a different architecture (e.g. Intel Core 2
vs. Intel Atom). You will have to try a lot of things out, because
theoretical considerations will be hard.


A good starting point is the "IntelB. 64 and IA-32 Architectures
Optimization Reference Manual" [1]. You can probably get a printed
copy, but once it's printed, it's probably outdated.


Regards,
Matthias-Christian


[1] http://www.intel.com/products/processor/manuals/index.htm
        http://www.intel.com/Assets/PDF/manual/248966.pdf



Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.