From: "Gurr, David (MED, self)" <David.Gurr@med.ge.com>
To: Noel Welsh <noelwelsh@yahoo.com>
Cc: caml-list@inria.fr
Subject: RE: ocaml, simd, & fftwgel RE: [Caml-list] Caml productivity.
Date: Thu, 1 Aug 2002 21:56:09 -0500 [thread overview]
Message-ID: <D4DBD8568F05D511A1C20002A55C008C09C294F6@uswaumsx03medge.med.ge.com> (raw)
Noel Welsh:
> There are a least two parallelising C compilers for
> the PC: Intel's and CodePlay's. CodePlay say they do
> a better job than Intel. I imagine Intel hold a
> differing opinion.
But do they do a better job than fftwgel or Spiral
or Atlas?
> I'm interested in knowing the deficiencies of these
> compilers. I imagine they run into problems with
> dependency analysis on complicated array expressions.
> Similarly, I'm interested in knowing in what areas HPF
> and SAC are performant. It appears to me that a
> functional language (where dependency analysis is
> simple) with array shape inference should be capable
> of creating very array fast code is almost all
> situations (and the SAC benchmarks show them beating
> HPF).
Is SAC available for public inspection?
>
> Cheers,
> Noel
I have not used either compiler. From the FFTW, Atlas, etc experience
the only way to get consistently high performance from a C compiler is
to do most of the work for the compiler and carefully feed it code that
it correctly optimizes. This is a compiler and application specific
trial and error process. FFTW does the optimization and scheduling for
the C compiler. Once you do this, it is much less clear what
the value added of the C compiler is. In particular, the amount of
refinement that would be needed to get ocamlopt to match C compilers
at this task might be relatively small. I have not read to code to
fftwgel but if fftwgel could be married to ocamlopt, they might well
produce code superior to intel or codeplay since C is notoriously
difficult to optimize even without SIMD.
-D
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
next reply other threads:[~2002-08-02 2:56 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-08-02 2:56 Gurr, David (MED, self) [this message]
2002-08-02 9:57 ` Noel Welsh
-- strict thread matches above, loose matches on Subject: below --
2002-08-01 15:36 Damien Doligez
2002-08-01 16:38 ` John Max Skaller
2002-08-01 16:55 ` Alexander V.Voinov
2002-08-01 16:45 ` Jonathan Coupe
2002-07-30 17:58 Gurr, David (MED, self)
2002-07-31 1:29 ` Travis Bemann
2002-07-31 8:09 ` Xavier Leroy
2002-07-31 8:39 ` Noel Welsh
2002-08-01 15:22 ` John Max Skaller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=D4DBD8568F05D511A1C20002A55C008C09C294F6@uswaumsx03medge.med.ge.com \
--to=david.gurr@med.ge.com \
--cc=caml-list@inria.fr \
--cc=noelwelsh@yahoo.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox