English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
[Caml-list] 32-bit Floating Format
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2004-06-20 (07:13)
From: David McClain <David.McClain@A...>
Subject: [Caml-list] 32-bit Floating Format
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 

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.

+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