Welcome to iraf.net Wednesday, November 22 2017 @ 09:46 PM GMT

IRAF on Intel Macs -- First Results

  • Thursday, January 26 2006 @ 06:21 PM GMT
  • Contributed by:
  • Views: 3,138
Apple
MachineBench Time
Dual 2.7Ghz G5, 2GB31 sec (ppc bins)
17" Intel/iMac, 1GB52 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.

IRAF on Intel Macs -- First Results | 8 comments | Create New Account

The following comments are owned by whomever posted them. This site is not responsible for what they say.

  • IRAF on Intel Macs -- First Results
  • Authored by: sirmarcos on Thursday, January 26 2006 @ 11:57 PM GMT
Well, that's exciting. Rosetta appears to be doing a decent job. That
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.
  • IRAF on Intel Macs -- First Results
  • Authored by: sirmarcos on Saturday, February 18 2006 @ 03:30 AM GMT
hey, those are pretty good numbers from the intel build. 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...

Anyway, the speed looks good. must be the improved integer
performance on the Core Duo relative to the PPC?
  • IRAF on Intel Macs -- First Results
  • Authored by: fitz on Saturday, February 18 2006 @ 04:11 AM GMT

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.

  • IRAF on Intel Macs -- universal binaries.
  • Authored by: sirmarcos on Monday, February 20 2006 @ 11:34 PM GMT

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:


CFLAGS= -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch ppc -
arch i386
LDFLAGS= -Wl,-syslibroot,/Developer/SDKs/MacOSX10.4u.sdk -
arch ppc -arch i386

bisector: bisector.o bisector_subs.o
	cc bisector.o bisector_subs.o -o bisector -lm $(LDFLAGS)

bisector.o: bisector.c
	cc -c bisector.c $(CFLAGS)
	
bisector_subs.o: bisector_subs.c
	cc -c bisector_subs.c $(CFLAGS)
	
	
	

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.

  • IRAF on Intel Macs -- universal binaries.
  • Authored by: fitz on Tuesday, February 21 2006 @ 07:10 PM GMT
For a simple hello.c the multiple -arch flags are all that's needed for a universal binary. Specifying '-arch i386' on a G4/5 will compile a native intel binary and it's this trick I was referring to in cross-compiling iraf packages i.e. simply set IRAFARCH to 'macintel' and let the system worry about setting the flags to produce intel binaries, all you need is to have the intel iraf libs installed. So, developers could install both archs but users still only need one.

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.
  • IRAF on Intel Macs -- First Results
  • Authored by: npirzkal on Sunday, March 05 2006 @ 09:10 PM GMT
IRAF does seem to load cleanly on my 10.4.3 OSX Intel but DS9 loads and then
exists with an Allegal Instruction message. Which version of a statically linked
ds9 have you tested?
  • IRAF on Intel Macs -- First Results
  • Authored by: fitz on Monday, March 06 2006 @ 02:53 AM GMT
The DS9 was 4.0b7 or whatever was current in the SAO archive at the time I tested. I can't speak to the Rice .pkg installer or SciSoft versions, but what do you mean IRAF didn't load cleanly? In any case, a beta of the port is imminent. -Mike
  • IRAF on Intel Macs -- First Results
  • Authored by: LBT_Dave on Saturday, March 18 2006 @ 05:48 AM GMT
The intel native binaries were posted one day after I installed the PPC version,
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.


Privacy Policy
Terms of Use

User Functions

Login