Slashdot Mirror

This sounds a lot like Acovea

They are citing it in the GCC summit paper. So I suppose they know it :)

This sounds a lot like Acovea

Genetic algorithms could take this a step further...

Yes, you're right.

What someone needs to do is set up an automated build system that uses "-fprofile-generate/-fprofile-use" -- especially for base system, multimedia, and compression libraries. I got something like a 12% speedup in using that for mplayer (or was that mpg123...) in benchmark mode, as opposed to stock ports compiler options under FreeBSD/amd64 (which, I believe, is "-O2 -fno-strict-aliasing", though many individual ports tweak those to the extreme). Granted, each program would need a decent corpus of representitive "work" to do for this method to be effective, but it could be done on port-by-port basis.

If someone wants to rock the world of Gentoo (and has more free time than sense), they should fork the project and incorporate the "profile" method I mentioned above *and* ACOVEA into an automated build system. Now *that* would be impressive. :)

I ran Gentoo for a couple years. I'm now running a mix of Ubuntu and OSX, mostly because to get all the software options I wanted, I couldn't pare down the libraries enough that my system was substantially different at the end from Ubuntu. I'd be sad to see Gentoo go downhill, though. There's a lot of value for the Linux community in people hammering on bleeding edge software. Where else would you have seen so much interest in applying genetic algorithms to find the best gcc optimization flags for compiling software?

There's competition now, and most machines owned by hobby-programmers and students will cruise through the compilation process fast enough that the "turbo" brand doesn't offer a compelling solution like it used to.

But some improvements could still possibly qualify for the "turbo" moniker:

1. Borland may have improved its compilers' optimizers, allowing your code's inner loops to go "turbo". G++ leaves a lot of room for improvement.
2. Incremental compilation and linking as the developer edits the source code, making compilation appear instant.
3. Borland may have improved the RAD tools, under the notion that if Amdahl's law prohibits significant speedups from compilation, speeding up the human behind the keyboard is the best way to increase net productivity.

Here is some data for you:
http://www.coyotegulch.com/reviews/linux_compilers /
http://www.mcsr.olemiss.edu/parallelogram/01_03/ic c.html#performance

First of all, -O2 or -O3 might not be the best choice - for each given piece of code, there is almost always some arcane combination of switches that produces faster (10 per cent or more) executables than -O2 or -O3. There is an open-source tool (acovea) to find the best combination of switches for a given program. See the benchmarks posted there.

Second, if you compile yourself, you can use icc (the Intel compiler), which usually (but not always) produces faster executables than gcc (see the benchmarks).

First of all, -O2 or -O3 might not be the best choice - for each given piece of code, there is almost always some arcane combination of switches that produces faster (10 per cent or more) executables than -O2 or -O3. There is an open-source tool (acovea) to find the best combination of switches for a given program. See the benchmarks posted there.

Second, if you compile yourself, you can use icc (the Intel compiler), which usually (but not always) produces faster executables than gcc (see the benchmarks).

I haven't read the article, since GTK+ is already my preferred GUI toolkit. And this in spite of the fact that I run KDE as my primary desktop! I run both Gnome and KDE, and my choice of KDE over Gnome is based more on organization and flexibility than it is on the underlying GUI toolkit.

As background: My wrote my first GUI programs back in the days of Window 3.1, and while most of my work is on data-crunching engines, I do write quite a few GUI applications. I need to rapidly generate an interface, back it with code, and have it presentable on Windows and Linux.

As a programmer, I don't like QT. It feels klunky, bloated; nor do I find QT Designer all that friendly. Beyond matters of taste and comfort, TrollTech requires a commercial license for certain tools (e.g., a MathML widget) that I can obtain under GPL for GTK+.

I'm rather fond of Glade. Most of my GTK+ GUI programs are in C, some in C++; I define an interface in Glade, fill in the appropriate functions, and I'm ready to rock and roll.

GTK+ 2.8 brought with it Cairo, a very nice drawing toolkit. I just put together a little interactive graphics application, just to better familiarize myself with Cairo, and the result is quite nice.

In the near future, I'll be writing some very extensive OpenGL applications, and I'll likely wrap these in a GTK+ GUI. If something better comes along, I'll try it -- but for now, GTK+ provides what I need. Your mileage may vary.

Quite clearly. And I accept that they optmize their compiler for their chips, and the other way around. But it is still a long way from optimizing for your own, to de-optimizing for the competitor, as long as the cpu calls is supported by both, which pretty much is the case with amd and intel. It is not the optimizing that is illegal...

A lot. It is the quickest compiler for x86 around. So people use it. And no, AMD has no compiler. They've made contributions to gcc, but they do not have one of their own

No, not interesting. Intel makes their own. AMD does not, but there is no market for what you suggest. People who make compilers will have to look at what the compiler should do, then figure out what chips to run it on, and then start optimizing for that chip using instructions. All the instructions is public, you can easily get them from amd.com or such.

Intel - Yes. GCC - Commercial? No. Microsoft - Yes.

you show complete lack of knowledge. GCC is dead slow against icc. Have a look at this article for some more information.

The benchmarks I've seen so far for GCC 4.0 haven't been too stellar. So, I'm guessing KDE won't see much of an improvement. It'd be interesting to benchmark GCC 4.0 against Intel's compilers.

Open Source software would not be as "good" today if it weren't for corporate cash. However, corporate cash has also distorted development of important packages like GCC and Linux, where minority platforms and user communities get marginalized because the developers are focused on the needs of their corporate sponsors.

Those are simply the facts of life; the needs of Red Hat, IBM, and Novell outweigh the needs of many users, simply through the application of cash. Adam Smith would be pleased.

My frustration is with companies -- big and small -- who use free and open software without attribution or support for the original author. A case in point: I've stopped updating and upgrading Jisp, my Java database engine, because too many people, ranging from Apache (who want to take ownership from me over the GPL) to SenseLogic use Jisp without even so much as a thank you. I've found closed-source products that blatantly ship my JAR file to customers -- and to add insult to injury, some of these companies send their users to me for free tech support!

I've had two commercial compiler companies and two major distributions -- including Ubuntu -- tell me that they want to use Acovea for optimization, but they don't offer any funding or support. And it isn't just corporations: How many Gentoo users have sent me a donation or code? Two. How many support requests have I had from the Gentoo community? Hundreds. Leaching from others is human nature; the corporations merely reflect the community in general.

Open Source software would not be as "good" today if it weren't for corporate cash. However, corporate cash has also distorted development of important packages like GCC and Linux, where minority platforms and user communities get marginalized because the developers are focused on the needs of their corporate sponsors.

Those are simply the facts of life; the needs of Red Hat, IBM, and Novell outweigh the needs of many users, simply through the application of cash. Adam Smith would be pleased.

My frustration is with companies -- big and small -- who use free and open software without attribution or support for the original author. A case in point: I've stopped updating and upgrading Jisp, my Java database engine, because too many people, ranging from Apache (who want to take ownership from me over the GPL) to SenseLogic use Jisp without even so much as a thank you. I've found closed-source products that blatantly ship my JAR file to customers -- and to add insult to injury, some of these companies send their users to me for free tech support!

I've had two commercial compiler companies and two major distributions -- including Ubuntu -- tell me that they want to use Acovea for optimization, but they don't offer any funding or support. And it isn't just corporations: How many Gentoo users have sent me a donation or code? Two. How many support requests have I had from the Gentoo community? Hundreds. Leaching from others is human nature; the corporations merely reflect the community in general.

Morton is correct.

Even at commercial companies, QA isn't a "sexy" task. People would rather bang out code than write testing harnesses and run benchmarks.

Also, free software is driven by programmers, who tend to hate QA. Like any artist or craftsman, a programmer hates having their work critiqued. They spent hundreds (or thousands) of hours on a program, only to have someone nit-pick the details and point out the flaws. But for art, "quality" is a subjective quality -- and with software, quality and reliability are tangible quantities that can be measured.

My Acovea project demonstrated the problem. Users of GCC love Acovea; many developers of GCC, on the other hand, seem to treat it is an annoying distraction. Acovea identified more than a dozen errors (some quite serious) in the GCC 3.4/4.0 compilers -- and yes, I did report them to bugzilla. Only a couple of GCC's maintainers have said "thanks."

Not that the cool reception deters me. I have a new version of Acovea in the wings, and will be unleashing it on GCC 4.x Real Soon Now. ;)

As a consultant, I've been paid to perform QA work on commercial software packages -- but only one company, and a big one at that, has ever contracted me to QA a free software project.

Right now, free software is about many things, but quality is not job 1. And that needs to change.

Oh comeon, gcc's well, just slow.
Slow to compile, slow when compiled.

I agree, to an extent. It's been said that Intel's compiler can outdo GCC in some performance benchmarks.

GCC is no slouch though, and obviously Intel is performing some tricks that could also be implemented by GCC.

I think it'd be a great move for AMD to work WITH GNU to optimize 64-bit AMD code from GCC.

Seems like Intel is more prone to keeping secrets when it comes to processors. Maybe this is (yet another) way for AMD to give them a run for their money.

Except the funny thing is fpmath=sse seems to be a strong way to HURT performance IRL. At least in several cases on both P4 and Opteron with gcc.

Check out acovea.
http://www.coyotegulch.com/products/acovea/acovea_ 4.html

"Some processor-specific options still do not appear to be a major factor in producing fast code.
Much to my surprise, I have yet to find any consistent evidence that options like -mfpmath=sse improve program performance. Thus Acovea bears out my personal experience, though it does not explain why so many people continue to suggest that I should use -mfpmath=sse to generate floating-point code. If someone could suggest a good "-mfpmath=sse", I'd appreciate seeing it."

Theres one for a start. I've never seen benchmarks for Borlands compiler, and there are a few high-end compilers which can out-benchmark even Intels compiler, but I don't have links to hand (Google for them)

After looking at this picture, I cannot doubt your hardcore hackerness at all. I have read your articles in DDJ dating back to 1989 or so and know you have great technical skillz...

But when I saw that pic with the taco bell large cup, pepsi can hiding a liquor bottle and mostly empty cup of Betty Crocker chocolate frosting, I had to admit that you are probably a true hacker of RMS proportions.

All joking aside, I have found your technical articles to be very useful; what things are you currently working on? I assume that this speed comparison between compilers has been research for another purpose.

Both Coke and Pepsi. What's the benchmark on those?

You can tell this guy is a nerd, but it goes far beyond the pizza and mountain dew... Is that really an empty tub of frosting sitting my his computer?? :)

But this can be a false economy, especially with programs that are used frequently: precompiled binaries will never run as quickly as those compiled with the right optimizations for your own machine.

Here comes the pain...

How can I tell which are the right optimizations? I assume precompiled binaries were compiled with gcc -O3. Beyond -O3 everything goes magic.

Instead of spending hours and hours doing profiling and testing I'll just gladly accept that my Firefox renders slashdot.org 1.05% slower.

Identifying the optimal settings can actually be non-trivial.

True. No task for a human. Tedious work.

But have you heard of this, a genetic optimizer for the compile time optimization parameters to GCC?

Oh and to start dreaming about new features: Maybe GCC can implement such a feature to find the best optimization parameters for each function which is being compiled? :)

Does Common Lisp lend itself easily to kernel, systems, or real-time programming on mass-market computer architectures?

I know that the developers of a popular PS2 game have disclosed that the game's business logic is written in Lisp

but would one want to write a 3D engine or a cellphone game in Lisp?

PS - in a recent dick-measuring benchmark (the "Coyote Gulch" floating-point ephemeris calculator), CMU Common Lisp and Steel Bank Common Lisp produced code 5% faster than GCC on a Pentium IV. The participants claim it was "an hour-or-so's work".

I've been arguing parts of this issue since late last week, when I was contacted by members of Apache Cocoon in regard to their use of my software, Jisp.

A few months back, I began migrating all of my "free" software from the libpng/zlib license to the GPL. Let's not get into the reasons why I made the change; the change is made, and I'm pleased with it.

The Cocoon people discovered my license change, and opened a dialog. In their view, my use of GPL would force them to remove Jisp from Cocoon. They requested that I either change my license or add Jisp to the Apache collective. Beyond a few miscommunications, the discussion was pleasant and educational.

My software remains under the GPL (or a commercial license, for those so inclined). I did not want to join Apache, as I have already committed myself to FOSS (Free and Open Source Software) projects that are more closely aligned with my business and personal interests. I did not want to "give" Jisp to Apache, either, given that I have several paying customers who might be uncomfortable with such a move --and my personal interest in keep Jisp a small, one-man project.

In the end, Cocoon may not even need Jisp , rendering this an intellectual debate as opposed to a practical one.

Most of Cocoon's members were quite polite; a few were quite pushy and arrogant, although some of that may be due to the crossing of language barriers. In the end, I think we've reached a point of mutual respect. People can disagree on these issues, and remain friends.

Licensing issues are rapidly approaching the contentiousness of fundamentalist religion; people are Balkanizing the FOSS world over the finer points of dogma, rather than building a common framework in which we can all thrive.

According to these benchmarks it doesn't.

The short of it is that GCC 3.2.1 is highly competitive with ICC 7.0, except for two cases:

FP-intensive code on the Pentium 4
Code that allows Intel C++ to auto-generate SSE vector code for it

Actually, GCC is really close to Intel C++. If you check out the benchmarks it's neck-and-neck on most code except for some Pentium 4 code and some numeric code. These differences are mainly due to Intel C++'s better inliner and automatic vectorizer. I do agree, though, that Intel C++ rocks. It's free for personal use on Linux, very GCC compatible, and almost as conformant as GCC to the C++ standard. It's also got extremely good error messages, which very important for C++ programmers.

Really? One numeric (i.e. HPC) benchmark using gcj which was investigated in detail here on Slashdot (almabench) was within a few percent of the best gcc time...not bad by most folk's standards. ;-)

We also investigated this. SWT is a _horrendous_ API which offers very little abstraction. You end up writing your code once for the Gtk+ target, and again for the native Windows target. It isn't really a cross-platform abstraction like WxWindows, and it's probably the reason why the Eclipse codebase is so large. You end up writing your application for each UI target platform. Gtk# runs and integrates with the platform instead, so you only write your code once.

As another poster pointed out already, this is completely incorrect.

BTW, I look forward to your forthcoming benchmark. Be sure to post the code.

It's pointless to interface with the threads layer directly when pthreads exists.

Another whopper. All a Java user sees is the Thread (or Runnable) abstraction...which native or emulated thread library is used doesn't matter. IIRC, gcj uses pthreads if desired (yes it does, I just checked).

Looks like you're taking the "big lie" approach to attacking gcj... I look forward to head-to-head performance comparisons with the aptly named "Mono". (Its a disease as far as I'm concerned.;)

I've been moving my work onto Linux, gradually, for several years now. I'm not an anti-Microsoft zealot by any stretch of the imagination; in fact, ten years ago, I was very pleased with many products coming out of Redmond. But as time has passed, Microsoft's products have bloated while their business practices leave a bad taste in my mouth.

Their licensing policies are the last straw; their greedy stupidities drive me nuts. Example: I bought a machine recently that came with a new copy Windows XP. I installed Linux on that machine, wanting to put the XP on one of my other boxes. But this copy of XP won't upgrade an existing installation of Windows 2000! Microsoft's reponse: I can only install the XP on a the machine it is "assigned" to!

Can someone please explain to me how Microsoft loses anything by my installing a "new" XP over an existing installation? Why do they care what machine I install the product on, so long as I've paid for it? Their arrogance is amazing; it is the result of corporate feudalism. I, for one, do not wish to be their peasant or peon.

As it is, I do 90% of my work on Linux now; I have only one Windows machine in my office, and it is used to simplify my interface with the MS world. But my next book is being written on Linux using AbiWord, LyX, and TeX, and I no longer take jobs that require MS products. A minor financial hit, to be sure, but a choice I can survive.

Microsoft lost me as a customer because of their attitude, not their product.

> And everything that came from RMS of the FSF is
> large, slow, and very ineffecient.

I take issue with that. Large, slow and very inefficient compared to what? If you compare vi and emacs you compare two very different tools. One is a a text editor, the other a whole development environment that can even do symbolic maths.

If you are talking about gcc I suggest you try to write a small, portable, standard-compliant, efficient C, C++, Java, Ada and FORTRAN compiler. Good luck to you. AFAIK gcc is unique, not even the BSDs have an alternative.

It's a good thing to complain about various shortcomings of available software packages, but here you are just repeating hearsay opinions that are not backed by fact.For example have a look at this site for a more unbiased study of gcc's performances.

Of course the comparisons were made using gcc 2.95.x (or 2.8 in the second article).

gcc has come a long way in terms of performance since 2.95.x. 3.2.x now compiles code that runs as fast (or faster, depending on the code) as Intel's C/C++ compiler. Right now, the only reason for me to use Intel's compiler is OpenMP.

Now, if anyone has made some benchmarks using gcc 3.2.x, I'd be interested. (In fact, I may have to do some on Monday.)

Tony

You mean this link? The one that shows GCC matching Intel C++ 7.0 on everything except the P4 FPU benchmarks?

I meant these!

GCC 3.2.x vs. Intel C++ 7 would have been interesting. This just isn't.

Go here for GCC 3.2 vs. Intel 7 information:
http://www.coyotegulch.com/reviews/intel_comp/inte l_gcc_bench2.html

GCC has done quite a bit to catch up.

Which APIs? Which bugs? Nothing is bug free. Also, your comment about "real time interpretation" is off base, see below.

Java isn't nearly as portable as they would have you believe (writing a 100-line applet and then running it on two different web browsers will tell you that.)

Applets apply to Java portability how again? Are you under the impression that some significant amount of Java development today relates to applets? Answer: not really. Further, if you use a decent JRE in both browsers you'll find you have no applet portability problems either.

Additionally, in my opinion, Java would have been much more useful if had been designed as a compiled (not interpreted) language.

Now you are exhibiting true ignorance for the world to see. There are many traditional, ahead of time, Java compilers. gcj, TowerJ and Jet come to mind. Look back at the recent article on x86 Linux numerics. Check out the linked article from that post - note gcj is only 9% slower than g++. Supposedly gcj 3.3 and 3.4 both improve gcj speed substantially over the 3.2 compiler used in that article...one guesses the more mature g++ will see less speedup.

In short, your reasons for liking C++ over Java don't hold water except for verbosity. ;-)

(BTW, I'll give you a strong reason for disliking C++ - you can't turn on bounds checking in STL arrays using operator[] without hacking STL. Ugly.)

In addition to the blindness shown by regulators in approving a dangerous Yucca Mountain site, another issue is at stake: the United States doesn't legally pown Nevada:

Stealing Nevada

No conspiracy theories, just good old-fashion adherence to what is supposed to be the law of the land.

And for those who don't care about the long-standing problems of Indians: Where do you think the U.S. government learned how to steal people's rights? If you want to defend your rights, defend those of others.

"Scott Robert Ladd has updated his GCC versus Intel C++ compiler benchmarks. This time round he includes updated results of the recently released GCC 3.1. The new version of GCC seems to be much better than its 3.0.4 predecessor, and GCC 3.1 even wins some benchmarks it lost previously over ICC. Overall, ICC remains a much faster C/C++ compiler, but GCC has successfully narrowed the gap. Read Scott's interesting conclusion at the end of the article too."

Modifying an article after publication is acceptable -- and it's a Good Thing if the revision fixes errors or omissions.

Modifying an article and not telling anyone is a Bad Thing called a "lie."

A case in point: Yesterday, I posted a benchmark comparison of Intel's "non-commercial" C++ compiler and gcc. Several people gave me suggestions for improving gcc's performance, and I updated the article today -- with clearly marked additions and explanations of what changed and why. That's journalism on the web.

What CNET is doing is called lying.

(btw s/stip/strip/ of course)

here is another benchmark icc version 5.0.1 with gcc 3.0.1. Note the difference is a lot smaller, except for the whetstone, which show interesting results (read the accompanying text).

Now, openmag people, see this site and how it documents the compiler options used, and how it makes the benchmark _source_ available for download. Read it and learn.

These benchmarks are done by Scott Roberts, who recently posted this to a gcc mailing list.

There's another Linux-only comparison between Intel 5.0.1 and GCC 3.0.1:
http://coyotegulch.com/hpc/intel_gcc_bench1.html

Note that Intel's compilers are available free for non-commercial work. I've written reviews of the Intel compilers, and my experiences suggest that Intel does, indeed, produce faster code than does gcc -- although not to the extent claimed in the Open Magazine article.

I'm no fan of Intel per se; read my article and Intel's responses for a full story. However, I'm not going to ignore Intel's delivery of high-quality Linux compilers for C++ and Fortran.

I'm using the Intel compilers (C++ and Fortran) for development of multiprocessing application; Intel supports OpenMP and gcc does not. Overall, I'm very happy with the Intel compilers, and recommend them to any serious developer. It never hurts to have more than one compiler, no matter what platform you're working on.

I've been closely following the Yucca Mountain investigations since the mid-1990s; my garage has hundreds of thousands (really!) of pages generated by various parties involved in this effort. I doubt DOE will continue to be so free with its literature, in light of "security cenrcenrs" raised by September 11th.

But I digress.

In a nutshell: "Approval" of the storage facility has been a foregone conclusion since the studies first began. Yucca Mountain was the only site studied, and any "problems" discovered have been ignored or glossed over.

The real problem is a lack of planning -- it isn't just the "Internet generation" who can't think ahead. Back when we began building nuclear power plants, no one thought about what we would do with the waste -- and so it now sits in over a hundred locations around the U.S., in hardened canisters sitting next to power plants. Because no one looked ahead fifty years ago, we now have a crisis on our hands, and little chance to make a rational decision.

The problem at hand: Nuclear waste needs to be stored somewhere, and Yucca Mountain is the only site selected for study. There may not be a rational, safe solution to the problem of nuclear waste -- and so Nevada's residents may take it in the shorts because of short-sighted and selfish politicians and

I say "may" because Nevadans are unlikely to lie down and "accept the inevitable." They're a feisty bunch, especially the ones who don't live in Reno or Lost Wages -- er, Las Vegas. The Ages Brush Rebellion is gaining strength again in the American West; confrontations between federal officials and local residents continue to rise.

You don't think this issue affects you? If you really think freedom is important, you might want to consider that Nevadans will be hosting nuclear waste that they did not create, as dictated by the federal government on behalf of big, stupid corporations. (Note: I like lots of businesses, even big ones -- but I have great disdain for stupid companies and people who impose their mistakes on others.)

For a somewhat different perspective on the issue, consider this article about the people who actually own Yucca Mountain:

Stealing Nevada

That article (which I am currently updating) has been published all over the world (search Google for it) in print and online. It won't make much difference, of course, because most people only care about right and wrong when it affects them directly. It's too bad, really; what the federal government is doing today with national IDs, intelletual property, and waste dumps is the direct result of letting them push other people around.

Good luck to those in Nevada, Shoshone, Paiute, and other-American alike. You need it...

I've been evolving algorithms for a long time now, using finite state machines (FSM) which can be easily moved across architectures and programming languages. Quite often, an FSM evolves to exhibit surprising behavior -- and given the complexity of the machines, it is impractical to understand why the FSM acts as it does.

Note that I said "impractical" -- given time, I could follow the FSM's logic and discern it's "thinking" (and I have done so with simpler machines).

If you want real, concrete information about genetic algorithms and artificial life, I suggest visiting ALife.org or the U.S. Navy's GA Archive.

Shameless plug: For five years, I've been developing a free (no ads) web site, Complexity Central, devoted to evolutionary algorithms, artificial life, and emergent behavior. I've posted several Java applets that demonstrate genetic algorithms, cellular automata, flocking behavior, and related subjects.

This is part of my Coyote Gulch web site, which contains lots of articles, web links, bibliographies, and free code in C++, Java, and Fortran(!).

I've been evolving algorithms for a long time now, using finite state machines (FSM) which can be easily moved across architectures and programming languages. Quite often, an FSM evolves to exhibit surprising behavior -- and given the complexity of the machines, it is impractical to understand why the FSM acts as it does.

Note that I said "impractical" -- given time, I could follow the FSM's logic and discern it's "thinking" (and I have done so with simpler machines).

If you want real, concrete information about genetic algorithms and artificial life, I suggest visiting ALife.org or the U.S. Navy's GA Archive.

Shameless plug: For five years, I've been developing a free (no ads) web site, Complexity Central, devoted to evolutionary algorithms, artificial life, and emergent behavior. I've posted several Java applets that demonstrate genetic algorithms, cellular automata, flocking behavior, and related subjects.

This is part of my Coyote Gulch web site, which contains lots of articles, web links, bibliographies, and free code in C++, Java, and Fortran(!).

...I wrote up a short "First Look" regarding the "noncommercial" (i.e., no-cost) versions of Intel's C++ and Fortran 95 compilers for Linux. I look at licensing, too, and have Intel's comments posted as well.

You can also look at some rudimentary benchmarks comparing gcc 3.0.1 and Intel C++ 5.0.

...I wrote up a short "First Look" regarding the "noncommercial" (i.e., no-cost) versions of Intel's C++ and Fortran 95 compilers for Linux. I look at licensing, too, and have Intel's comments posted as well.

You can also look at some rudimentary benchmarks comparing gcc 3.0.1 and Intel C++ 5.0.

...I wrote up a short "First Look" regarding the "noncommercial" (i.e., no-cost) versions of Intel's C++ and Fortran 95 compilers for Linux. I look at licensing, too, and have Intel's comments posted as well.

You can also look at some rudimentary benchmarks comparing gcc 3.0.1 and Intel C++ 5.0.

... I never expect a "real" response to anything I send my CongressCritters.

Back in my days as a radical right-wing leftist, I wrote dozens and dozens of letters to government officials, ranging from Bill Clinton to Bruce Babbitt (Sec. of the Interior) on a variety of social justice and environmental issues. Real letters, neatly presented, correct grammar, polite, all that stuff -- and what did I receive in response?

From Mr. Clinton's office, I received a very consistent set of form letters signed by a staffer, usually thanking me for expressing support for the President. Of course, they were replying to a letter wherein I'd strongly declared my lack of faith in his leadership. Clearly, they never actually read what I sent -- or if they read it, they didn't want to respond to my actual words.

Back then, I was in Colorado (damn, I miss it), and the best responders were Sen. Ben Campbell (who helped me with some DOI FOIAs), and US Rep. Scott McInnis. Other CongressCritters and the Executive Branch sent form letters that often had nothing to do with the subject of my letter! I'd write about nationalizing the workforce, and "Clinton" would thank me for support NAFTA (which, in its current form, I don't support!)

Ugh. Very disheartening. Which is one reason I stopped lobbying as an individual. Too much work writing a letter for no discernable affect.

I didn't want to use the article as an ad, but if you insist... ;)

Java Indexed Serialization Package
LifeBox - A Cellular Automata Simulator
Traveller - A Genetic Algorithm for Solving the Travelling Salesman Problem

...and much more to come, when i get the time to get it documented and posted.