* [Caml-list] 32-bit Floating Format
@ 2004-06-20 7:13 David McClain
0 siblings, 0 replies; only message in thread
From: David McClain @ 2004-06-20 7:13 UTC (permalink / raw)
To: caml-list
Back during the gamer discussion about the virtues, and lack thereof,
of 32-bit single precision floating point format, a comment was made
casting aspersions at this format for computations but allowing its
virtue as a storage format.
Prior tests of mine in the previous 5 years showed that double
precision, and indeed, extended precision, formats were computationally
more efficient on conventional FPU architectures. (e.g., X86 and
Pentium archectures, 68K FPU's, SPARC, etc).
But now, we have arrived at the decision to perform computer image
recognition on modern DSP's and the new G4 and G5 Power PC
architectures. The Altivec engine, for example, only gives its blazing
speed for 32-bit floating point formats. (at least on the G4... perhaps
the G5 also allows 64-bits?)
All of a sudden, we are facing the need to support massive computations
in this more meagre 32-bit format (er... actually only 24 bits). I
still have questions in the back of my mind about just how far we can
push these calculations before error buildup overwhelms us. But the
Altivec is definitely being pursued, as are 32-bit floating point DSP
architectures, based purely on the speedup that appears possible.
I am just beginning my investigations on the limitations of this
format. I am using OCaml for this purpose -- actually a derived
language called NML to support ad-hoc vectorized calculations from even
more terse program statements. The beauty of OCaml (the underlying
implementation language for NML) is its relative ease of interfacing to
a C foreign function interface, in addition to its ease of use as a
FPL.
NML retains the syntax and gross semantics of OCaml, but the typing is
dynamic and loose. So NML does not qualify as a strongly typed and
provably correct language. It is instead a language of extreme
convenience along with extensive graphing capabilities for easy
interpretation of aggregate numeric results.
But if anyone out there has prior experience using the Altivec for
single precision computations, I would appreciate hearing from you
about your perceptions and measurements of the accuracy of large
vectorized calculations. If we are wasting our time it would be good to
know sooner than later.
24 bit processing seems acceptable for audio work and one dimensional
signal processing. But 2-D processing on images compounds the errors.
This is mitigated to some extent by the fact that image kernels and
dimensions are typically much smaller than audio stream chunks.
On the Pentium architectures, I have had considerable success using
OCaml for audio DSP work in conjunction with Intel provided
high-performance single and double precision Math Kernel Libraries and
Signal Processing Libraries. However, under OCaml, most of that work
was restricted to double precision floating point computations. Even
so, I found that I could support enormous data rates, far exceeding
even the highest practiced 192 KHz sampling rates, even on older
Pentium II architectures, and all programmed in OCaml.
I am only now starting my work with the Power PC, having just ported my
Ocaml based NML these past few days to a brand new PPC workstation.
David McClain
Senior Corporate Scientist
Avisere, Inc.
david.mcclain@avisere.com
+1.520.390.7738 (USA)
-------------------
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
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2004-06-20 7:13 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-06-20 7:13 [Caml-list] 32-bit Floating Format David McClain
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).