Actually, yes I do. A little while ago I was doing some micro-optimizations (i.e. not algorithmic), using gcc 3.3 and icc v7 on FreeBSD and testing the results on a number of processors available to me: Athlon XP, PIII and PIV Xeons.
With my problem/code the Intel compiler generated code ran faster on the Athlon XP than gcc 3.3's code using its XP switches and other "go fast" options. Using whole program optimization resulted in a program running considerably faster than the gcc 3.3 generated binary. icc is also stricter in some ways regarding syntax and C++ gets to use the EDG parser (if its still using it, can't see why not).
The various posts here from people going "why bother" show a great deal of naivety. There are good reasons you want to use multiple compilers other than just the fact that icc can generate better code than gcc (in many circumstances, other tests may show the opposite result, YMMV). For starters its going to pick up a different set of errors. Now gcc is pretty good at producing useful warnings, a whole bunch better than Visual C++ for instance, but it isn't perfect, adding icc into your toolkit helps you find problems in your code. A more important reason however is to avoid the mono-culture introduced with everyone using gcc. Years ago we called it "all the worlds a VAX", then it became "all the worlds a Sun", now its "all the world's Linux (with gcc)". A bit of variation (in implementation, not interface) is a good thing.
In my code I use a few simple defines to map the Winsock stuff to BSD sockets and program to the Winsock interface. You can't do all the things you want to do but for simple things it suffices.
#define SOCKET int
#define closesocket close
#define SOCKET_ERROR (-1)
#define INVALID_SOCKET (-1)
(and headers to suit, invent null wrappers for the startup/cleanup stuff too).
Other things to watch out for:
You have to use recv() and send() (or recvfrom()/sendto()) rather than read/write and deal with short
writes correctly.
Beware of the Winsock stream socket (TCP) close behaviour. If you don't recv() up to the FIN a closesocket() will send a RST. Causes no end of trouble that one.
* Adobe has a PDF specification document online, but it is incomplete. There are some PDF files Acrobat can read, but those specs don't describe. Whenever someone publishes how to read those files, Adobe has him arrested.
Would you care to back up this claim? Alhtough it's not a counter-proof I know of two groups who have implemented from-scratch PDF renderers that are yet to encounter documents using undocumented features. The PDF specification is quite large (1000+ pages) and some things are relatively obscure so it can sometimes appear that documents are doing things not in the spec.
That was APRA (Australian Performing Rights Assocation, not to be confused with the other APRA - Australian Prudential Regulatory Authority) who sued Telstra, not ARIA but they're in bed together. APRA look after the writing royalties for their members, ARIA enforce the reproduction rights.
By the time BS was doing C with Classes ld was in C (had been since v6). So he can't use that as an excuse:) But you're right, C++ would be quite different if he'd written a linker.
Firstly its transputer and occam. No capitalization. And occam didn't rule. In many ways it sucked. No data structuring (until occam 2.5 by which time it was too late) and numerous painful limitations to ensure appropriate semantics for checking for parallelism mistakes. occam's variant of CSP was cool but others (Rob Pike) had done it before the Inmos crowd and in some repsects in a better way. The reason the transputer was popular was its floating-point unit which at the time was the dog's balls, the links and relatively high integration (add crystal and away you go). From a s/w point of view they weren't all they were cracked up to be. The T9000 would've been good with the routing done for you
but the others had caught up by the time the bugs got ironed out and inmos dropped the ball.
Oh, BTW this Sun stuff is nothing like transputers and their links. It's chip-level interconnect to avoid pads.
Occam did reasonably well at CSP things (Rob Pike's newsqueak did it better however) but fails at almost everything else.
I recall Inmos stating "We want to make occam the FORTRAN of parallel processing." My reply was "You have."
(ref. to lack of data structuring other than fixed sized arrays).
It wasn't until the hacked up occam 2.5 that it got some better programming language features.
Okay he valued his NeXT, so did we (we had about 30 of them in a corp. R&D lab building h/w for them, doing systems s/w etc...) My point was that the original HTML viewer didn't do a great deal.
The authoring tools for Doom were done on the NeXT. Also, the original Berners-Lee web browser was pretty lame, even for that time, given the graphical abilities of the platform and toolkit.
The article states NeXT created Objective-C. They didn't. Brad Cox did. NeXT did however add a couple of things and implement Objective-C in gcc (and get in a fight with the FSF) but they didn't create the language.
Slashdot Mirror
See this paper. I remember reading the original document in (CACM IIRC) and was pleased to see it updated showing just how far "forward" we've come.
With my problem/code the Intel compiler generated code ran faster on the Athlon XP than gcc 3.3's code using its XP switches and other "go fast" options. Using whole program optimization resulted in a program running considerably faster than the gcc 3.3 generated binary. icc is also stricter in some ways regarding syntax and C++ gets to use the EDG parser (if its still using it, can't see why not).
The various posts here from people going "why bother" show a great deal of naivety. There are good reasons you want to use multiple compilers other than just the fact that icc can generate better code than gcc (in many circumstances, other tests may show the opposite result, YMMV). For starters its going to pick up a different set of errors. Now gcc is pretty good at producing useful warnings, a whole bunch better than Visual C++ for instance, but it isn't perfect, adding icc into your toolkit helps you find problems in your code. A more important reason however is to avoid the mono-culture introduced with everyone using gcc. Years ago we called it "all the worlds a VAX", then it became "all the worlds a Sun", now its "all the world's Linux (with gcc)". A bit of variation (in implementation, not interface) is a good thing.
#define SOCKET int
#define closesocket close
#define SOCKET_ERROR (-1)
#define INVALID_SOCKET (-1)
(and headers to suit, invent null wrappers for the startup/cleanup stuff too).
Other things to watch out for:
Would you care to back up this claim? Alhtough it's not a counter-proof I know of two groups who have implemented from-scratch PDF renderers that are yet to encounter documents using undocumented features. The PDF specification is quite large (1000+ pages) and some things are relatively obscure so it can sometimes appear that documents are doing things not in the spec.
That was APRA (Australian Performing Rights Assocation, not to be confused with the other APRA - Australian Prudential Regulatory Authority) who sued Telstra, not ARIA but they're in bed together. APRA look after the writing royalties for their members, ARIA enforce the reproduction rights.
Sounds like a job for the Media Lab. Forget the Teddy Bears guys.
Small point (or maybe not)... Mach wasn't from Berkeley. Try CMU.
There are so many good papers though. You just have to read them all :)
N-10 was the project moniker for the Intel i860 (the wonder chip we all got excited about at the time).
And Amazon made money. These are the end days my friend, the end days.
By the time BS was doing C with Classes ld was in C (had been since v6). So he can't use that as an excuse :) But you're right, C++ would be quite different if he'd written a linker.
They were. Read all about it.
Oh, BTW this Sun stuff is nothing like transputers and their links. It's chip-level interconnect to avoid pads.
Helios. The Atari transputer workstation used it.
Wrong band.
SF predicted this too... See "The Marching Morons".
Including NeXT (IB is pretty much the same) its been, oh, only about 15 years.
Mate, you're not supposed to tell the foreigners about Coopers! They'll take it all. Now keep 'em distracted with talk of VB, New, XXXX, etc...
PS. Tassie beers - Boag's and Cascade - aren't half bad and Hahn is okay too.
The transputer was not a vector machine, not unless you count the move2d instruction :)
I recall Inmos stating "We want to make occam the FORTRAN of parallel processing." My reply was "You have." (ref. to lack of data structuring other than fixed sized arrays).
It wasn't until the hacked up occam 2.5 that it got some better programming language features.
Okay he valued his NeXT, so did we (we had about 30 of them in a corp. R&D lab building h/w for them, doing systems s/w etc...) My point was that the original HTML viewer didn't do a great deal.
WriteNow was okay for small notes and the such. In our lab we used the NeXT port of FrameMaker.
The authoring tools for Doom were done on the NeXT. Also, the original Berners-Lee web browser was pretty lame, even for that time, given the graphical abilities of the platform and toolkit.
The article states NeXT created Objective-C. They didn't. Brad Cox did. NeXT did however add a couple of things and implement Objective-C in gcc (and get in a fight with the FSF) but they didn't create the language.
It doesn't have to be larger. I have plenty of anti-gravity devices. I'm sitting on one right now.