Slashdot Mirror

Compilers matter, and Intel makes some damn good ones. So if your research calls for lots of performance on little budget, that can influence language choices. Heck same thing on supercomputers. That is not my area of expertise, but it isn't as though all compilers for a given supercomptuer will be equally good. If I were to bet, I'd say the FORTRAN compilers are some of the better ones.

Uh, not as much as you think. It's not an order of magnitude difference. here are some benchmarks from a very good Fortran compiler. Gnu compilers are nearly always good enough. What you may run into is that there are SIMD instructions that exist on Intel chips that generic compilers may not have access to. On the other hand, you can make use of them from gcc, so it's just a combination of factors.

(Also, blind use of optimization flags results in troubles, once you accidentally start throwing IEEE math out the window... depends on your application, of course.)

Bearing in mind that M$ software, services and support were far cheaper and of a much higher quality in those days. The manuals were excellent, tutorial disks were provided free etc. then the good people left and the ass wipe remained and basically M$ now reflects the morals, integrity and qualities of a typical failed jockstrap insurance salesman.

Those same qualities will of course bring about the fall of company from being a leader to a historical note in the evolution of computer technology.

Autovectorizing does exist Absoft makes a product called VAST http://www.absoft.com/Products/Libraries/vast.html
It works on C, Fortran, and C++. I've seen some reasonable performance gains from just a recompile.

OS X screenshot'

Overall the fonts looks blurry. The "C" in C/C++ isn't the same width allover the curve. The "T" in target looks like it's bolded. th "9" looks just weird with all widths at the same time on the lines. The "B" in build looks like ass. Is it the same font?

Overall Linux fonts looks just as good as these. The "D" char you rave about is hardly noticeable and certanly much nicer then the "B" on the OS X shot.

Take of the Apple glasses before posting.

Besides gfortran, which is part of GCC, there is also the free g95, with compiler binaries for Mac OS X, Linux, and Windows -- see http://www.g95.org/ . G95 currently supports almost all of Fortran 95, unlike gfortran. Absoft sells their own Fortran 95 compiler for Mac OS X, in addition to IBM's -- see http://www.absoft.com/ . NAG has also has an F95 compiler -- see http://lists.apple.com/archives/scitech/2002/Jul/m sg00076.html .

At my company we built a 8 processor 4 node cluster of opterons to run finite element modeling. Big Memory being the motivation. The limiting factor was finding a fortran that ran in 64 bit and the only one out there ran only with the SUSE distro. We also had a motherboard burn out. I think the main hurdles to a 64 bit world is catch up right now theres only one choice when it comes to alot of things.

mister troll, absoft sells a f95 compiler for osx. nice try.

Since my main apps arent written with the altivec in mind (they are in fortran and have branches inside loops), i'm hosed.

I'm thinking about getting this for an upcoming project.

I have FORTRAN, I have Pascal, now hurry up and finish my COBOL compiler!

Seriously, I started out programming for the Classic Mac OS in Pascal ages ago, but haven't touched it recently; with all the C, Java, etc. tools now available for OS X Pascal has been, quite correctly, left by the wayside. It feels kind of archaic to me now, and I gather I'm not alone ...

-- shayborg

And if you think that "this is a fair reflection of the performance a user can expect on normal code", because the norm for programs would be to be simply compiled with the "normal" compiler, you also have to use the results from the MS compiler, not from gcc or Intel.

One more thing, while c't said they used the Absoft Fortran compiler, they did not mention wether they also used the "VAST-F/Vector - preprocessor which automatically inserts AltiVec instructions in your code."

All right, I'll concede on the gate count issue. I'd be interested to see how many are dedicated to cache as opposed to processor logic.

Athlon, for instance, is already copper and is moving to SOI by 2004. I think Intel is already SOI, but is slower moving to copper. I guess what I'm saying is that neither of those two factors are likely to be an issue going forward.

The G5 is an upcoming 32-bit embedded chip made by Motorola (like the G4 and G4+), and does not resemble the (64-bit) Power4's internal architecture in the slightest. Whether this chip will be the basis of the next generation of Macs is of course not yet known.

According to the Motorola PowerPC roadmap, the G5 will be available in both 32 and 64 bit versions. How much it resembles Power4 isn't clear, but it's supposed to debut at up to 2 GHz. Are you still so confident it won't have world-class performance?

Because Apple does not have the integrity (nor, according to the oft-repeated excuse, the FORTRAN compiler) to submit SPEC runs for a G4-based computer, there are no official SPEC scores for the G4. However, we do have Motorola's *estimated* *SPEC95* scores for the 7450 (a.k.a. G4+) at 733MHz. (Here [motorola.com], second page, on the left.)

For what it's worth, I agree that Apple should do SPEC benchmarking itself. Especially now that MacOS is Unix.

On the compiler front, I did find a seemingly decent FORTRAN compiler for MacOS X, so that issue is addressed at least. ;-) (Absoft is a respected compiler company.)

I must say I'm surprised at how low that 'estimated SPECfp95 score' is. I'd really like to see more information on G4 fp capabilities. The Absoft compiler claims to have auto-vectorizing capabilities using Altivec, which might have considerable impact on some of the benchmarks. (The new dual-processor 1 GHz G4 is claimed to have 15+ GFlops of computing power, using Altivec I presume.) I guess my next step should be to actually purchase a Mac and get busy benchmarking. ;-)

As to your estimated SPEC scores, I appreciate the effort but I doubt those are worth much.

Power4 is simply not a desktop chip design. Even using one of the 4 dies in the MCM as the basis for a desktop CPU is a shakey proposition, since they're too big (again, 400mm^2 on .18um), and include a bunch of integrated I/O stuff and the L3 TLBs, all stuff which would be worthless in a desktop machine. The actual datapaths are quite simple, and indeed are optimized to work in an 8-way MCM, not as the sole CPU of a desktop machine.

The integrated I/O might or might not be worthwhile, but Apple's current pro machines use L3 cache. What would really be of interest on the desktop, of course, is the execution efficiency that manages to retire so many instructions per clock. If that single Power4 CPU was really "optimized to work in an 8-way MCM", it truly did a stellar job as a uni-processor.

Rumor also has it, BTW, that the G5 will include an on-chip memory controller allowing memory bandwidth to scale in SMP systems, similar to the scheme used in Hammer. I wonder when Apple will release SMP boxes with more than two CPUs...

At any rate, thanks for a more interesting discussion than usual. :-)

299,792,458 m/s...not just a good idea, its the law!

Check out Project Appleseed for an example of a MacOS cluster supercomputer.

Yes, it's getting a bit old now (G3/266 beige towers.) Imagine what they could do now.

There are also no vectorizing compilers for the PPC 7400; the Metrowerks compiler will do inline AltaVec assembler, but it doesn't recognize vectoizable loops autmoatically and it doesn't support the linga franca of scientific computing (i.e. Fortran).

Some of what you are saying is greek to me, but here's a link from the Project Appleseed site seems to answer the need for a Mac OS Fortran compiler: Absoft Fortran 77 compiler.

Rather just read the text-intensive abstract on the system? Appleseed Report

--