1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
|
<html>
<head>
<title>Why IEEEIO</title>
</head>
<body bgcolor="#F0F0F0">
<!-- <img src="Images/ieeeiotitle.gif">-->
<h1>Why use IEEEIO?</h1>
<DL>
<DT><b>Its compact</b>
<DD>On the SGI Origin 2000, the entire library is 206k.
It contains only a little over 2,500 lines of code for
the C++, C, and F77 versions combined.<p>
<DT><b>Its fast</b>
<DD>Most simulation applications end up writing a lot more
data than they read, the I/O interface is optimized for
maximum writing speed. No seeking is required during writing
and the low-level raw unix I/O interface
is used to maximize performance.
Preliminary <a href="Performance.html">performance tests</a>
show that it is
comparable with f77 unformatted IO for writing
speed.
Data is translated to the
machines native representation <i>(ie. byte-swapping)</i>
only during reading.
If speed is required for reading as well, then there is a
<a href="Utilities.html#convert2native">'convert2native'</a>
utility which will optimize the file
for the type of machine that is reading it.<p>
<DT><b>It interoperates with HDF</b>
<DD>If you use HDF-SDS, you should have no problem using IEEEIO
because they share the same programming interface. You
indicate the type of file you want to use when you open
the file. From there on, the same subroutines are used
for reading or writing data to the file, whether it be HDF
or IEEEIO. In addition there is an
<a href="Utilities.html#ioconvert">'ioconvert'</a>
utility that can translate
either direction between IEEEIO and HDF files and preserve
all of the HDF annotations and NetCDF attributes.<p>
IEEEIO doesn't supercede HDF. It is designed
to be a lightweight IO system which you would use when
the broader functionality of HDF is not required.<p>
<DT><b>It is crash-safe</b>
<DD>Since no seeking is required to maintain file integrity
during writes, you will not lose data if the
simulation program exits without having properly
closed the file.<p>
<DT><b>Most machines use IEEE standard floating point number
formats</b>
<DD>When HDF and XDR were first created, almost every machine
architecture had its own native floating point representation.
There were VAX floats, Cray floats, and Convex floating point
representations... all mutually incompatible. Now, virtually
every major supercomputer architecture supports IEEE standard
floating number representations. The primary differences
between number formats now it the byte-order which is trival
to convert.
As a result, the XDR and HDF support for platform neutral
floating point formats is more work than is necessary for
most machines. By depending on
IEEE standard number formats, the data storage can be made
much simpler and more efficient.
If
the machine you use doesn't support IEEE floating point
numbers, then you should continue to use HDF. Since IEEEIO
interoperates with HDF, this does not require significant
modifications to your code to switch back and forth between
the two. Currently IEEEIO has been ported to SGI IRIX {5.x,6.x},
IRIX64 6.x, HP-UX 9.01, ConvexOS {on SPP-1200 and SPP-2000},
DEC Alpha OSF/1, and the Cray T3E. The only machine that is
not supported is the Cray C90.<p>
<DT><b>Why not use XDR?</b>
<DD>
So if the aim is to create a lightweight portable binary file
format, this leads to the question of why not use XDR for the
encoding? Well the answer is that in early testing it was
discovered that HDF is significantly faster and more efficient than
XDR. So if you really need XDR then you should be asking
yourself <i>why not use HDF</i>?<p>
Again, this file format is
primarily designed to take advantage of the fact that most of
the operations that XDR and HDF do to make the data platform
neutral are not always necessary given current binary formats
for floating point numbers. It also leads to a very simple-to-parse
file structure which brings us to the next point...
<p>
<DT><b>Simple file structure</b>
<DD>Its extremely simple file structure makes it
easy to build readers in a variety of languages.
This is important for interpreted data processing
languages like IDL because the reader can be implemented
in native IDL instead of writing native methods.
The same is true of Java. Instead of creating native
methods that directly call the libieeeio interfaces,
the format is simple enough that it can be implemented
using java itself.<p>
</DL>
<hr>
<address><a href="mailto:jshalf@suttung.aei-potsdam.mpg.de">John Shalf</a></address>
<!-- Created: Mon Apr 7 12:52:52 MDT 1997 -->
<!-- hhmts start -->
Last modified: Tue May 27 18:14:25 CDT 1997
<!-- hhmts end -->
</body>
</html>
|
