Welcome to iraf.net Thursday, April 18 2024 @ 02:47 PM GMT
IRAF on Intel Macs -- First Results
- Thursday, January 26 2006 @ 06:21 PM GMT
- Contributed by: fitz
- Views: 3,756
| Machine | Bench Time |
|---|---|
| Dual 2.7Ghz G5, 2GB | 31 sec (ppc bins) |
| 17" Intel/iMac, 1GB | 52 sec (ppc bins) |
| 21 sec (intel bins) |
I got my hands on an Intel iMac recently and did some quick looking around and testing. The surprising news is that for the most part the existing PPC macosx binaries will run without change using the emulator! A statically linked DS9 also works, as do the X11IRAF tasks.
Update: (2/7/06) Initial port work is complete and native binaries are working. As a benchmark comparison using a script that does some real-world reductions consider the table here (YMMV): See below for other notes and updates as we get a chance to do more on this (borrowed) machine.....
Signal handling in the CL and error handling from tasks likewise works (or not) as under the PPC OSX. FPE handling has been broken for a while and similarly fails under the emulator, however memory violations are properly trapped and most tasks seems to work.
Image display (using DS9 for now), imd overlays and graphics all work. Quick tests of both .imh and FITS images show that the byte-swap issue isn't a problem.
As expected however, compilation is broken using the stock system. This is easily fixed however by defining the following environment variables in your .cshrc file to allow cross-compilation of ppc binaries:
setenv XC_CFLAGS="-arch ppc"
setenv XC_LFLAGS="-arch ppc"
setenv XC_ FFLAGS="-ppc"
The $hlib/f77.sh must also be trivially patched to accept the "-ppc" flag as follows:
141a142,145 > -ppc) CFLAGS="$CFLAGS -arch ppc" > shift > ;; >
The "-arch ppc" flag is specific to Apple and this permits the locally compiled SPP programs to be compiled as ppc binaries, the other flags allow linking to the ppc iraf binaries.
See the table above for some rough benchmarks. I'm very impressed with the fact that the ppc binaries work at all. (Update: Memory usage for each iraf process using the ppc binaries appears to be 4-5 times more than on a G4, e.g. ~120Mb is used for each of the cl.e, x_system.e, etc. ). Using native i386 binaries (yes, that's the architecture reported) returns to the normal memory usage, about 1/4th of the emulator needs.
The following comments are owned by whomever posted them. This site is not responsible for what they say.
explains the big memory usage of course. I assume X11 comes with
on the intel MacOS x 10.4.4 discs and can be installed, as well as the
x11 dev tool kit needed to compile things.
other than IRAF, IDL and fink, every other program I used today
already has a universal binary. Those are rather key programs to
getting work done, of course, but still. The intel transition seems to be
less rocky than the 68k to ppc transition. All because Apple controls the
developer tools, I think.
many external packages will need to be patched to build on intel...or do
they use enough IRAF source that they'll build inside the cl running on
a native intel-mac iraf port...
Anyway, the speed looks good. must be the improved integer
performance on the Core Duo relative to the PPC?
I wonder how many external packages will need to be patched to build on intel...or do they use enough IRAF source that they'll build inside the cl running on a native intel-mac iraf port...
It won't be too bad: Some of the recent GCC build issues have already been addressed in the port and there's nothing new in the Intel OS X that isn't already a problem under ppc OS X. The release will have binaries for both macosx/macintel (might as well update both) and I think it should be possible to allow for cross-compilation, i.e. even if you don't have an Intel Mac a developer should be able to compile binaries on their ppc system so they can distribute binaries for their package. In theory the same should be do-able for the various linux flavors but I'm not up to dealing with the linux ports at the moment.
Well, that's cool. Until today, I hadn't figured out how to make an intel binary from the command line with the latest OS X dev tools. I could do it in Xcode, both with my IRAF Button program, and with some command line c programs I've written... but I didn't know what I needed to put in the makeflie I need to do to the makefile to make it happen without the Xcode IDE... the -arch flag never seems to work.
After googling today, though I came across this page
http://developer.apple.com/documentation/Porting/ Conceptual/ PortingUnix/compiling/chapter_4_section_3.html
So my (very simple) makefile now looks like:
Walla, the Finder says it's a "universal unix executable" and it's about twice the size of the PPC only one.
So it might be possible to make "universal" binaries of IRAF, if this trick can work on a larger scale. THough that'd be twice as big a download.
The size of universal binaries is not a minor issue for IRAF: a typical IRAF+STSDAS+TABLES system would run 1GB, most of it wasted space. A UniBin XGterm might make be okay, but we've already got the concept of architectures in IRAF and most people will only want one or the other binary anyway.
exists with an Allegal Instruction message. Which version of a statically linked
ds9 have you tested?
so I wiped the 'old' stuff and installed the Mac/Intel port of iraf. I only had
to make slight modifications to the standard install procedure, such as I did
not need the 'z' option in the tar commands (archives uncompressed on
download) and setenv is not the correct command under the bash shell my
system defaulted to using (use export under bash).
In order to start iraf from within an xgterm I had to modify the shell script
/iraf/iraf/unix/hlib/cl.csh where the 'mach' environment variables are set for
Darwin. In both cases, the setenv commands include '='s that should not
be there. Both looked like simple typos. They are about 80 lines down
in the shell script. The two (non-consecutive) lines should read:
setenv mach macintel
setenv mach macosx
Other than that everything has worked well, but I have yet to do any real
reductions.
Dave.