Slashdot Mirror

I'll get to your relocatable code question , but as an aside, you might want to check out Ecos from Cygnus. I haven't dealt with rom based code for several years now, so I don't know much about ecos. But it comes from Cygnus, is free source (not GPL; their variation on the Mozilla license), and who knows, it may even be ported to your setup.

In general, processors have two kinds of addresses for data and instructions: absolute and relative. Absolute is faster since no airithmetic is involved. A .o file has the symbol name, a static link resolves it immediately, and a dynamic linker resolves it at load/run time.

Relative branches are slower because of the arithmetic, but on some machines the instructions can be quite a bit shorter because a full address is not necessary. Of course, this itself may make enough of a speed difference to cancel the arithmetic, and the code size reduction may be worthwhile too. The linker probably has to compute relative distances at link time.

None of this helps directly with your request for BIOS code, but if you want that just to figure out how it copies code, you may not need it. If your processor supports relative addressing, you probably don't. Make sure you can do everything you want with relative addressing. Some processors are troublesome this way, at least memory says so, but I spent 7 years on just m68k, so I'm a bit hazy on others now.

Of course, you may still need absolute addressing if system subroutines are at absolute locations in low or high memory, and if you have memory mapped I/O.

--

An SPR is a Software Problem Report. When a bug is found or an enhancement is requested an SPR is created to track the changes to the code base. The term is often used interchangebly with Software Change Report (SCR) and bug report. Check out GNATS. Its the GNU SPR-tracking tool.

Perhaps what they mean is "porting, along with their compiler suite, to their Intel boxes, the 320's and 540's"?

Another, even better option -- Cygnus' Cygwin. Quite a bit of commonly-used open source software is already ported (most GNU stuff compiles out of the box, but there's lots of other stuff full of Linuxisms that needed to be ported better.) It has the added advantage of being able to run on 95/98 as well, although with substantially fewer features (like file security.)

In addition, Cygwin seems to still be actively maintained. EGCS is available for it among other things (to be fair, the same guy that ports EGCS to Cygwin also does it for UWIN.)

why not attack Cygnus for holding back source code to the GNUPro tools that are available as binaries only?

Because the only stuff from Cygnus available as binaries only isn't GPLed? The GNUPro FAQ claims that "As part of our commitment to Open Sourceware, Cygnus provides source code with all releases of the GNUPro Toolkit." (Note that "provides source code with all releases" doesn't necessarily imply "makes the source code available from our FTP site"; they don't have to make the source conveniently available, they just have to make it available to those to whom they've distributed the binaries - and can't prohibit those to whom they've distributed the binaries from further redistributing binaries or source to GPLed programs).

mmm-hmmm. Here is one solution our company is hoping to use: Jazz.
Jazz is a 2D scenegraph rendering API in java. If you've ever done any 3d work, you'll know that a scenegraph is basically a bunch of primitives (polygons, text, curves) organized in a tree structure with linear matrix transforms between nodes. This lets you scale, flip, stretch, etc. any portion of your scene simply by tweaking the values in a single transform node. More importantly, this lets you ship an arbitrarily complex user interface over the netwerk merely through specifying your initial scenegraph (with the addition of some serialized callback objects + wiring) followed by commands that mutate various nodes on the scenegraph.

But - it is fast. Very fast. And a lot of Java is based on C (syntax, etc) - a cut-down, partially redisgned version of C++ could look very similar to Java and be one heck_of_a_lot faster - even a Java-To-C++ translator that gave you C++ code to compile would probably end up faster than the native Java!

Well, the language design by itself isn't necessarily slow (although all the reflection APIs would definitely drag down any implementation). It really is the VM that makes Java annoyingly sludgy. There are a few competing efforts for a native Java compiler, the most prominent being GCJ.

Oh well. Will nothing ever be done Right??? :-(

nope.

It'll be a long rocky road for Linux if all of the Linux community had this "Open Source or F--- Off" attitude.

I'm all for the development of open source software, but it's going to be a while before Postges or MySql is up to the speed of Oracle, before KWord is up to Microsoft Word, before Gnumeric is up to Microsoft Excel, before GCC is up to commercial compilers, before KDeveloper is up to Code Fusion, before GnoMoney is up to Quicken, before....

There is a slow shift to open source software, that is clear. But it's not happening overnight, and there will be a place for commercial applications for quite a time to come. If all the "Microsoft Windows" software ran on Linux today, wouldn't you agree that Linux would probably have a more rapidly expanding user base? And, it the end, this would help the development of open source software?

If you notice, GCC is managed now by Cygnus, and without thier commercial products, they wouldn't have two nickels to rub together, much less host the GCC/EGCS web site, cvs site, ftp site, or the staff to help development of the compiler.

Slashdot itself is running on a MySQL database, which, if you were not aware, is NOT open source, it's commercial (to an extent). So, your post has at least been rendered up by a commercial product.

Really, I think the Linux community at large would be best served to get off of it's GPL evanglist soap box. Personally, I find no harsh things to say about the BSD licence, it's a valid licence, and I would rather see people use the BSD licence that "invent" a licence of thier own like Sun, AOL/Netscape, and Apple have done when they say they are supplying an "open source" product.

Check out Cygnus.

"Cygnus Solutions is the open-source software leader."

Cygnus has had explosive growth. I would guess that most of their revenues come from support of open-source software. They release and maintain a lot of open-source software.

Why does Cygnus involve itself in commercial closed-source product development and sales? If open-source has been a model that has provided such a profitable market for Cygnus, what is their rationale for creating and selling closed-source products?

Has Cygnus actually performed any marketing studies? Do they know, for a fact, that this actually optimizes their earnings? And, what about the long term? Open-source alternatives are being developed. Will Cygnus be able to compete with the open-source alternatives? Especially when selling into the Linux market?

Time will tell, but I'd like to believe that when open-source alternatives are available, they will ultimately have more features that people need, they will be more stable and I would tend to choose them because I know I can depend on the source if I have a problem and the company peddling it has gone away, or no longer supports the product. I also wonder about releases of this product on different architectures and if I'll ultimately be somehow tied to using some set of Linux distributions to use closed-source products on Linux.

Don't get me wrong. I appreciate all that Cygnus does for open-source. I would like to understand their approach to the marketplace. If there is real data that supports their hybrid approach, I'd like to know about it. Perhaps Cygnus has studied it and sees that there are limitations to providing open-source support only and that to survive you need commercial closed-source products as well. Their original business model was support of open-source products and I'd like to know why they've modified this.

I believe Intel is working with (and invested in) Cygnus to help GCC with Merced compatibility and performance. Anyone else know of any official statements?

2. What kind of performance do they get compared to something like the Athlon?
8. Where can I get one?
Actually, there's a couple of other vendors that you should be ableto get one from, VA Linux comes to mind a s possibily. API may have a list ofvendors on their site, but I'm not sure.

As far as performance goes, the '264s are todays king-of-the-heap for numerical (FP-intensive) computation, but you definitely want DEC (Compaq)'s Alpha compilers (with Linux versions now available for beta-test-- because they use the Alpha predicated instructions (and some other technical stuff about bit-alignment vs. byte/word alignment in "gcc), they will perform 20-30% better than EGCS gcc, which itself will do much better on Alphas than the previous "standard" gcc 2.7.x or 2.8.x (the latest 2.9.5 is egcs gcc).

The Cygwin project has mainly focused on increasing the scope of the supported Unix APIs and increasing correctness. But the team has increased performance a fair amount in the last year. For example, I believe last time we compared djgpp compile times with those using the equivalent Cygwin-based compiler on the same platform, the Cygwin one was only off by something like 5%.

The cool thing about having an emulation layer like Cygwin is that it makes it pretty easy to quickly port over the latest and greatest Linux open source software to Windows.

But yeah, if you really want a native Win32 compiler with no Unix compatibility, mingw32 is the way to go. And once the new x86 gcc backend gets integrated in, Cygwin and mingw32 versions of gcc will both generate significantly faster-running code than Visual Studio for PII systems...

Geoffrey Noer
noer@cygnus.com
Cygnus Solutions

There is one serious practical problem with Open Source on Windows.

What do you use to compile it?

Using Microsoft tools is problematic, as they don't support familiar makefiles, they change often and there are a number of grungy places that require even more #ifdefs than you would have with Unix-like systems.

Also, I think that Open Source is not advanced by requiring a pricey language platform purchase before you can get started. Open Source, in my observation, has greatly benefitted because people with few resources can really contribute, and contribute right away.

There is cygwin, but it's not entirely mature. Also, there is the issue of cygwin.dll licensing. I personally feel that releasing a library under GPL and selling another licensed version of the same library is against the spirit of Open Source. It is explicitly granting a license to one group of users that another group does not hold. This license issue probably frightens away a lot of potential workers to improving cygwin. Has RMS ever weighed in on this issue?

There is a call for people to help with the cygwin project, currently. If the tools were really mature, the split licensing wouldn't bother me so much as I believe that a ton of Linux software would be ported to Windows if cygwin could really do it. One really great benefit to this is that people would upgrade more often from Windows to Linux when they compared their poorly performing Open Source code running on Windows/cygwin to what they could be doing on Linux.

It might help if a commercial Linux distro, or perhaps a Power Tools CD, included the full cygwin package, complete with all the known ported releases of Open Source software. You could cross develop cygwin on Linux with a Windows target. Such a thing might be used to spread GPL software through the Windows community more. A good free X-Server might be handy here too.

There is one serious practical problem with Open Source on Windows.

What do you use to compile it?

Using Microsoft tools is problematic, as they don't support familiar makefiles, they change often and there are a number of grungy places that require even more #ifdefs than you would have with Unix-like systems.

Also, I think that Open Source is not advanced by requiring a pricey language platform purchase before you can get started. Open Source, in my observation, has greatly benefitted because people with few resources can really contribute, and contribute right away.

There is cygwin, but it's not entirely mature. Also, there is the issue of cygwin.dll licensing. I personally feel that releasing a library under GPL and selling another licensed version of the same library is against the spirit of Open Source. It is explicitly granting a license to one group of users that another group does not hold. This license issue probably frightens away a lot of potential workers to improving cygwin. Has RMS ever weighed in on this issue?

There is a call for people to help with the cygwin project, currently. If the tools were really mature, the split licensing wouldn't bother me so much as I believe that a ton of Linux software would be ported to Windows if cygwin could really do it. One really great benefit to this is that people would upgrade more often from Windows to Linux when they compared their poorly performing Open Source code running on Windows/cygwin to what they could be doing on Linux.

It might help if a commercial Linux distro, or perhaps a Power Tools CD, included the full cygwin package, complete with all the known ported releases of Open Source software. You could cross develop cygwin on Linux with a Windows target. Such a thing might be used to spread GPL software through the Windows community more. A good free X-Server might be handy here too.

There is one serious practical problem with Open Source on Windows.

What do you use to compile it?

Using Microsoft tools is problematic, as they don't support familiar makefiles, they change often and there are a number of grungy places that require even more #ifdefs than you would have with Unix-like systems.

Also, I think that Open Source is not advanced by requiring a pricey language platform purchase before you can get started. Open Source, in my observation, has greatly benefitted because people with few resources can really contribute, and contribute right away.

There is cygwin, but it's not entirely mature. Also, there is the issue of cygwin.dll licensing. I personally feel that releasing a library under GPL and selling another licensed version of the same library is against the spirit of Open Source. It is explicitly granting a license to one group of users that another group does not hold. This license issue probably frightens away a lot of potential workers to improving cygwin. Has RMS ever weighed in on this issue?

There is a call for people to help with the cygwin project, currently. If the tools were really mature, the split licensing wouldn't bother me so much as I believe that a ton of Linux software would be ported to Windows if cygwin could really do it. One really great benefit to this is that people would upgrade more often from Windows to Linux when they compared their poorly performing Open Source code running on Windows/cygwin to what they could be doing on Linux.

It might help if a commercial Linux distro, or perhaps a Power Tools CD, included the full cygwin package, complete with all the known ported releases of Open Source software. You could cross develop cygwin on Linux with a Windows target. Such a thing might be used to spread GPL software through the Windows community more. A good free X-Server might be handy here too.

He almost used Java and the Kaffe VM instead of C according to an old interview. His most interesting comment was about Java being a superior language to C, and what sounds like his willingness to write q4 in Java (if it is possible by then with a java->x86 compiler like gcj)

specifications are elegant and graceful, by necessity

You must be reading different specifications than the one I've been reading...

Sean

People known to be working on getting GCC working better on Alpha are: Richard Henderson, David Mosberger, Catherine Moore. If you think any OS that uses GCC is something you would like to support, thank these people, and the others at GCC/EGCS, they are the ones that will give you the freedom to run something other than WinNT and Tru64 on your Alpha.

Try Cygwin, which apparently will serve ('tho it's NOT free if you are porting commercial applications...). According to its FAQ, it now supports both their Unix-like API and the native Windows foo.

• http://sourceware.cygnus.com/ml/cygwi n-xfree

Here

Citation..
(1) Code Fusion produces code that is 85 percent faster than the current Net GNU release, 20 percent faster than the Microsoft Visual C++ 6.0, and equivalent to Intel's Proton compiler. These results are based on the Integer Index performance in the byte benchmark.

What do I think is lacking in Win2k? UNIX!

Have a look at Cygwin , it provides a fairly full Unix environment where many programs will compile out of the box.

Done. The PII backend that Cygnus donated is now 28% faster than M$ VC++. Read it from Cygnus' datasheet here.

Hmm, I read on their web-site that the PII backend is 28% faster than M$ VisualC++ and compares with
the Intel Proton compiler. So, gcc is now the fastest x86 compiler on the planet (read it here.)

As of the upcoming 2.95 release, ecgs == gcc. One and the same. Since the new backend won't be integrated before 2.95 comes out, that pretty much answers the question.

You might have also noticed that the link heads to a machine called egcs... 8-)

EGCS will become GCC. If I recall correctly, when EGCS is "finished", it will be released as GCC 3.0. In the meantime, EGCS releases are numbered as GCC 2.9x and EGCS 1.x in parallel, it appears.

Poke around egcs.cygnus.com for the complete scoop, as I'm sure I don't have my facts 100% straight (although I have them close).

It would appear Intel is trying to keep its x86 flavor more attractive than other x86 flavors by stacking the compilers in its favor as well. I might be cynical, but I think that Intel is banking on getting a few of the ducats that people are saving on Open-Source Software by having them upgrade to an Intel x86 instead of an AMD or Cyrix part.

After all, the compiler supports Intel-specific optimizations, so why not?

The problem, of course, is the fact that AMD and Cyrix probably do not have the resources to fund/promote similar efforts, so this does end up being a means for Intel to un-level the playing field.

On the bright side, alot of x86-specific tweaks will help all x86 variants, not just Intel's x86s. (For instance, register allocation that understands the highly non-orthogonal IA32 register file would be a big step forward for all x86's. There was an interesting paper in MICRO-31 about that, IIRC. Also, scheduling to avoid AGIs and other hazards generally helps all flavors.) So, the picture isn't as bad as the paragraph above might have painted.

Nonetheless, if you want AMD-specific tweaks to GCC, then why don't you see if you can contribute to the tweaking effort? Even if all that means is beta-testing proposed changes on your machine for robustness and performance improvements, it'll still help. Poke around egcs.cygnus.com and ask what's up.

According to the change log, a question and another question on the egcs mailing list, exceptions are thread-safe.

Oh well, I'll soon find out for myself.

According to the change log, a question and another question on the egcs mailing list, exceptions are thread-safe.

Oh well, I'll soon find out for myself.

According to the change log, a question and another question on the egcs mailing list, exceptions are thread-safe.

Oh well, I'll soon find out for myself.

i agree, i just started a winnt project using msdev. My first order of biz was to download
cygnus cygwin and vim for nt.
I then bought a book called "MFC Programming from the Ground Up" which goes though mfc basics with out any ide.


Its quite empowering developing mfc code using vi/bash and NOT using the "class lizard" to break/hack/comment up my code..and cripple my mind...and i know in the end ill have an intimate knowledge of mfc... for what its worth..that is...... because hopefully someday soon gtk/qt will be the primary gui toolkit for nt/unix/mac!!

-greg

In spite of Sun's attempt to keep Java in a corporate stranglehold, the free software community has produced several virtual machines (check out Kaffe and Japhar), a classpath implementation ( GNU Classpath), and a conformance test (see Mauve).

None of these are complete, but all are impressive and because of the GPL/ LGPL they will always be free software. Sure, Sun and other vendors offer the latest and greatest bells and whistles. Free software is inexorable -- it will catch up. I can wait, and those who can't are welcome to use proprietary products until then.

Check on Cygnus' native Java compiler. It's totally GPL'ed.

http://sourceware.cygnus.com/java

I basically agree with this. I haven't paid for a copy of Linux yet--my current distribution is RH 5.1 [boo hiss, I know] installed from a friend's CD, and before that I actually installed Slackware 2.0 via FTP over modem and SLS [remember that?] from about 30 floppies.

But....

Do the business models for open source really work, especially the first, most-cited one, selling support? Cygnus isn't just selling support, they're selling stuff you don't get by going with gcc alone (read their FAQ, particularly the last question).

And while it's true that there will be people who will buy Red Hat just for the technical support, ultimately will there be enough--can there be enough? One of the arguments for Linux has been the "you can get technical support in a newsgroup for free immediately" shtick. And whether or not it's politically correct, for a lot of people the "free beer" part is just as important as free speech. Even if I do pay Red Hat directly for my copy of Red Hat 6.0, if I then put it on 100 machines their profit has effectively evaporated.

No one can (or at least no one should) argue that open source doesn't produce high-quality software and doesn't have the potential for dazzling development speed, and it can certainly have a place at commercial software companies. But if you can buy my products for a thirtieth what I charge you for and you have no reason to buy my support because you can get equivalent support for free, isn't it only a matter of time before I go out of business?

Some of the more interesting pieces, like LSF, are only licensed by Sun, thus will not be included in this `deal.' (For a free improvement over LSF, check out GNU Queue. If it doesn't do something you want, you can support the community and extend it.) If you read the announcement carefully, you'll see that the only new codes to which it applies are the parallel file system (the Sun CTO thinks distributed file systems are dead, anyways), the Prism debugger, and the parallel run-time environment.

Of those, the only with no available substitute is the debugger. The ROMIO library is a good place to start for the MPI file I/O stuff (a good database would be a better place, imho). I already mentioned queue management software. The Ptools Consortium and the Globus Project have links to other HPC cluster tools.

Many of the pieces for debugging are available (combine ddd and gnuplot), but some notable ones are missing. The ability to control multiple GDBs easily from one processes and the visualization of parallel execution are needed, and quite difficult to implement. There seems to be interest in making GDB easier to use from other processes, which is a good start towards solving the larger problem of general, distributed debugging. And both the mpich and LAM MPI implementation have some profiling information, but few tools to dig through it.

To be fair, Sun has contributed (and supported contributions) to the original packages. Why they are releasing the rest under their Exploit the Community license is beyond me.

Jason, ejr@cs.berkeley.edu

Why? EGCS (the next gcc) already supports several 64-bit architectures like Alpha and UltraSparc, and incorporates the Haifa scheduler which can be a big performance boost.

Let's see how it compares to IBM'snew java (of course, IBM is still at 1.17 vs Sun's 1.2)

Let's see how it compares to Cygnus native Java compiler (10X improvement over JDK, seamless C++/Java integration.)

Get it here.

Now that EGCS is available under a more rapid release schedule, you probably won't need GNUPro just to get your code to compile, but it might be a good deal if you want the latest PII/PIII optimizations that haven't been rolled into the public codebase yet. You also get a visual debugger and some other goodies.

Here's a press release on the PII/PIII optimized GNUPro tools that will be available next quarter.

Some additional information from the egcs web pages maintainer:

www.gnu.org now has the announcement, so I have just added a (small) announcement to our web site at http://egcs.cygnus.com/.

The current egcs release is 1.1.2; at http://egcs.cygnus.com/egcs-1.2/sched ule.html you will find rather detailed information on the forthcoming 1.2 release.

Some additional information from the egcs web pages maintainer:

www.gnu.org now has the announcement, so I have just added a (small) announcement to our web site at http://egcs.cygnus.com/.

The current egcs release is 1.1.2; at http://egcs.cygnus.com/egcs-1.2/sched ule.html you will find rather detailed information on the forthcoming 1.2 release.

As a member of the egcs steering committee, which will become the gcc steering commitee, I can confirm that yes, the merger is official ... sometime in the near future there will be a gcc 3.0 from the egcs code base. The steering committee has been talking to RMS about doing this for months now; at times it's been contentious but now that we understand each other better, things are going much better.

The important thing to understand is that when we started egcs, this is what we were planning all along (well, OK, what some of us were planning). We wanted to change the way gcc worked, not just create a variant. That's why assignments always went to the FSF, why GNU coding style is rigorously followed.

Technically, egcs/gcc will run the same way as before. Since we are now fully GNU, we'll be making some minor changes to reflect that, but we've been doing them gradually in the past few months anyway so nothing that significant will change. Jeff Law remains the release manager; a number of other people have CVS write access; the steering committee handles the "political" and other nontechnical stuff and "hires" the release manager.

egcs/gcc is at this point considerably more bazaar-like than the Linux kernel in that many more people have the ability to get something into the official code (for Linux, only Linus can do that). Jeff Law decides what goes in the release, but he delegates major areas to other maintainers.

The reason for the delay in the announcement is that we were waiting for RMS to announce it (he sent a message to the gnu.*.announce lists), but someone cracked an important FSF machine and did an rm -rf / command. It was noticed and someone powered off the machine, but it appears that this machine hosted the GNU mailing lists, if I understand correctly, so there's nothing on gnu.announce. I don't know why there's still nothing on www.gnu.org (which was not cracked). Why do people do things like this?

Chill is the "CCITT High-Level Language", where CCITT is the old name for what is now ITU, the International Telecommunications Union. It is is language in the Modula2 family, and targets many of the same applications as Ada (especially large embedded systems). Chill was never used much in the United States, but is still being used in Europe, Brazil, Korea, and other places.

Can anyone sum up the differences between egcs and gcc and explain why they haven't been combined up until now?

Here is a list of new features in egcs 1.1:
Link

As one of the co-maintainers of the Debian EGCS packages, I'm extremely happy about this. I've found the EGCS developers quite responsive about bug reports, and often found bugs in release versions to be fixed in snapshots already.

Yeah, Henry Spencer is way cool. Even if you don't count his work on stuff like the regexp package, there's his postings on usenet, notably in the C newsgroups and the sci.space newsgroups. In a landscape dominated by ignorant flamers, Henry Spencer has always been out there very calmly posting corrections. I've had Henry Spencer autoselected in nn for years.

And man, John Gilmore was one of the founders of Cygnus...

Kids these days, they don't know anything...

• Henry Spencer
• John Gilmore

1. Mozilla's Clue stick
   Gnome's Clue Stick
   egcs Clue Stick

That's the subject of their contest. Hit their website for details.

--Corey

I have to admit that I am biased (in large part due to my employer). I would not consider a dual PII generally a good multiprocessor for numerically intensive codes. This has nothing to do with Intel or Linux, or g77/pgf77/absoft, etc.

What I have found on my codes is that small (actually tiny) problems run well on pentia. But reasonable research sized problems cause it to huff and puff. Machines like the alpha or the R10k (and R12k) kick serious butt on the larger problem sizes. What is just insanely cool is to watch your code (efficiently) use all 32 processors, and get something like a 28-30x speedup.

But, as I said, I am biased.

Back to fortran. Jeff Templon has an excellent page on Linux and Fortran. Better is the big fortran link page. This is really a nice resource and is a nice intro to the general Fortran Market setup by Walt Brainerd. I strongly advise visiting this site if you need to think Fortran.

Ok, now some thoughts. Craig Burley and crew have done a positively bang up job on g77. It is IMO a useful productive research tool... with a caveat or two.

First, it really is just a front end to the gcc back end, so there are many... gcc-isms... floating about.

Second, while optimization is OK, it is generally tied to the gcc optimization, which has traditionally not been very good. The egcs project has had a much better track record on getting real optimization into the compiler. Folks, if your runs can take years, 5% DOES matter. Optimization on pentia is not just -O, you need things like

-O3 -malign-double -malign-functions=2 -funroll-loops -ffast-math

among others for decent performance.

Third, and most important for me, it (nor egcs) knows nothing whatsoever about multiprocessing.

In short, g77 and egcs in general are awesome tools. But unless you work on small problems, they are not suitable. You will need some better tools, and that involves passing over some money in this case.

I like the Portland Group tools, though the KAI tools are effectively identical to what you use on big supers like Origins. Unfortunately, I do not think KAI supports Linux any longer. Maybe we can all write them a nice letter on how they could drop support for some underused platform for computation (some come to mind here :-) ) in favor of Linux. Market size and all that.

As the author of the referant article wrote, most fortran users want all the speed they can get, so you need to look at what your code spends the most time doing, and figure out if it is doing it the right and most efficient way, or if your system is correctly designed for speed, or if you are hitting one area of your system really hard, and thus causing a bottleneck. In short, if you need to design for speed, start out with a workstation design, and not a PC design. You likely will need massive memory and IO bandwidth to complement an insanely fast CPU. Putting an Alpha into a PC architecture should be considered a capital crime. It makes much more sense to put it into something like a DS20, a T3E or some other design (I can fantasize about an Alpha in an Octane or an Origin, that would be a complete screamer... a memory and IO bus capable of feeding the processor at its full speed... shudder).

The language and its implementation are important, but so is the fundamental system design. You need to avoid bottlenecks everywhere.

Joe

I wanted to hail to the original "Cygnus" so I scratched my brain for a spell-out for "Swan". I got the spell-out from Cygnus' name for open source / free software ... sourceware. So my submission is "SourceWare ANswers". And to help matters, there does not appear to be a swan.com.
Christopher A. Bohn

fyi the GCJ frontend to gcc is a part of the EGCS project

feel free to contribute to this wonderfull project

fyi the GCJ frontend to gcc is a part of the EGCS project

feel free to contribute to this wonderfull project