They certainly did a lot of pimping of the word "innovation" during the anti-trust trial, but this seems to be genuinely innovative stuff to me.
It's not quite "innovative" in the sense that it hasn't been done before, but it certainly hasn't been done well. So if Microsoft really pulls it off it might quite rightly be a major coup.
There are related efforts in the free software community as well. The GCC project has implemented object-level compatibility between C++ and Java, for example. It's not quite seamless, and never can be owing to langauge differences. But it's a nice starting achievement, to which I hope other OO languages will be added in the future.
Actually there is a ring of truth to what bubbha is saying. I can provide a little technical background.
The Visual Basic language and runtime are historically single-threaded and event-driven. The Java language has been multithreaded from the start, yielding two distinct advantages for server programming:
it greatly simplifies concurrent processing
multithreading can leverage SMP
The reason VB is not completely crippled by its lack of threads is a feature of COM known as a single-threaded apartment, or STA. This allows COM to marshal in-process requests to/from VB and other languages, even if the latter is multithreaded. Requests to an STA are queued on the Windows event queue, and are considerably slower than direct method invocations.
To achieve concurrency with VB components, one usually must instantiate a pool of components, dispatching each request to an available component. Microsoft Transaction Server (MTS) conveniently provides this capability. This is not without its drawbacks, for example separate VB components created this way cannot see each other's memory (or they would violate the single-threade constraint) so some other means is necessary to share state.
It is my understanding that a future release of VB will be multithreaded. That's not surprising except that it has been a long time coming. Part of the difficulty may have to do with COM itself, which implements automatic resource management with reference counting. The main advantage of reference counting is simplicity. Among the drawbacks are performance problems, especially with multithreading (the increment/decrement operations must be atomic, which cannot be done cheaply on x86.) Compare with a tracing collector which is found in many JVM's and is very well suited to multithreading.
I haven't yet studied Microsoft's CLR. It'll be interesting to see what they add to COM to get around its problems.
Doing this kind of parallelism extraction in the compiler just plain makes more sense than doing it on the chip (with SMT).
He was talking about the compiler. The fact is, with the vast majority of code achieving a high level of ILP with compiler technology is a extremely difficult problem with no easy solutions. GCC tries very hard to achieve ILP on RISC architectures too. The standard tricks are well-known, but not nearly good enough to keep 8 integer units busy. (In some cases it may be provably impossible.)
Even if IA-64 solves the ILP problem, there is still the memory latency barrier. For those reasons many (myself included) are not so optimistic about IA-64 performance in the long haul.
And it's also why RedHat is screwing over their users by sticking with gcc over SGI's
(GPL'ed) IA-64 compiler
I have no doubt that SGI's compiler is better suited to IA-64 today, since the backend was written exclusively for that chip. GCC's goal of compiling for every hardware is still worthwhile.
Btw GCC is not "Cygnus' baby", it belongs to the FSF. And the FSF has specific rules concerning contributed code that have nothing to do with Red Hat.
GCC is a large, complex project of well over a half million lines of code and a complexity that can take months to master. Yet it stands as an exmaple of a large project with its origins in free software (unlike Mozilla).
Yet it steadily attracts contributors, most of whom tend to master small portions of the system leaving the rest to others.
Of course GCC has quite a bit of corporate sponsorship, which doesn't hurt any...
I've seen many young candidates with good technical experience lacking in business experience.
For what it's worth, managers tend to respect the latter.
Anyway, most of the "technical" jobs I've applied for (mostly in IT) were really business positions. When you have to write a scope of work or interview the customer, that's business. Sadly, there are relatively few opportunties available in pure computer science.
... obviously the pages were fast when compared to Java servlets.
Not obvious. Servlets are among the fastest way to get dynamic content, capable of hundreds or even thousands of page generations per second from a single uniprocessor. Please prove your claim.
and also C# can use classes written
in other languages which i found very interesting.(and java has yet to find a way to do it).
Incorrect. First, there exist compilers for numerous languages that translate to bytecode. Second there are interpreters like JPython and Jacl, if you want to marry scripts to your Java classes. Third, projects like gcj offer an alternative to pure Java that lets you easily marry Java/C++ code.
Desktop computing does not significantly benefit from an alpha.
You might as well say "desktop computing does not significatly benefit from Linux." That would be no more or less true.
The fact is people run Linux because they want something different or better, or they are just bored with Microsoft OS's. For all of the same reasons, some prefer Alpha to x86.
If I have to pay 3x the hardware cost (Cheapest alphas I've been able to find start at $4.5K),
You haven't looked hard. New UP1100-based systems can be found for about half your figure. Good used equipment regularly shows up on Ebay for $1000 or less.
why wouldn't I run Tru64 with the DEC compilers since they won't release optimizations for GCC?
A few reasons spring to mind:
Tru64 compilers really aren't much faster, especially on integer code, compared with the soon-to-be-released GCC 3.0.
Compaq has ported their C/C++/Fortran compilers to Linux anyway.
People are happy running Linux/x86 without compilers from Microsoft or Intel.
One could offer that RedHat has done an
end-run around this issue with gcj
Many feel there ought to be a free Java. Kaffe is one, gcj is another, yet the free VMs haven't caught on, presumably because they lag behind the Sun releases (inevitably so).
but this technology is still somewhat flaky
Nothing flaky about gcj... it's just not released yet. (Ignoring the 2.95 release for a moment, 3.0 will be much more complete.) The code is about what you'd expect from a development snapshot.
and arguably if you aren't compiling to the JVM, you should probably be using C++ anyway.
You think the VM is the only benefit of Java? Regardless, gcj has a rather nice bytecode interpreter in its runtime, and offers a nice hybrid of bytecode with compiled core classes. You'd be surprised how well it performs without a JIT, especially the load time.
Although Linux does support console on the serial port, so if that "rack mount device" you speak of is a basic term-server/serial port switcher, you can manage your x86 Linux boxen the same damn way.
True, almost. Just hope you don't have to perform any BIOS changes from a serial console. You can't compare the poor excuse of firmware that ships with most PCs to OpenBoot.
The Blackdown Project has Sparc ports. 1.2.2 is available, though I don't believe that 1.3 is yet.
Good point. The Blackdown folks do fine work. But it's still no match for the Solaris 1.2.2 Production VM. Our server apps have to be robust, fast, robust, high performance, robust...
(I'm hoping the gcj project will become the great equalizer on Java performance, but it's not quite there yet.)
Chances are, if you have a Sparc machine, it
drained at least $10,000 from your wallet and it's running Solaris 7/8.
So now who's making assumptions? We buy rack-mount SPARC hardware regularly, for general purpose servers. They are not Sun branded, they are built on OEM hardware, and can be purchased new for about $2300 and up.
It's easy to justify buying the SPARC hardware over x86:
No surprises on chipsets, disk controllers, etc. Everytime we buy an x86 server it seems we need to download some new driver to make it work. Not so with SPARC.
Excellent overall performance. The 440MHz US-II isn't quite as fast as the newest Athlon and PIII systems, but it's certainly close enough, and the 2MB L2 cache is blazingly fast.
Remote management. No need for klunky KVM switches. One rack-mount device can manage 8 SPARCs by a serial console, allowing complete remote control from a single IP address.
Most of our SPARCs are running Solaris today. I'm considering installing Linux on some of those to simplify management: it's easer to manage a network of Linux machines than a mix of Linux and Solaris. The main criteria is whether we need a JVM... those running Java are stuck with Solaris for now.
There is so much free and commercial Java and COM libraries available for JSP/Servlet and ASP or Cold Fusion developers, but not for PHP.
That's partly true. ColdFusion however tries to be portable, with availability on NT, Linux, Solaris, and others. COM certainly isn't available on all those platforms.
For that matter, when using PHP on Windows, you could write your own COM bindings... you have the source.
That is to say, the availability of COM isn't so much a language issue as a platform issue.
I think perl is actually better, but for true speed I'd use C.
Do you really want to spend half your debugging time chasing memory leaks and SIGSEGV traps? *shudder* There are far better choices than C for long-running server applications.
DON'T use tcl, or you will regret it.
So what's wrong with Tcl? AOLServer is actually quite capable, it'll hold its own against PHP etc.
Incidentally, our experience with ColdFusion is very similar; the scripts are difficult to debug and test, performance is miserable for any complex pages, and the server fails for reasons that are difficult to explain.
Many "features" of ColdFusion, i.e. memory management, are mostly undocumented and poorly understood. I have had CF scripts that exhaust server memory (yes, 1GB of memory) until I "tweaked" them slightly.
But is it really that more expensive? I thought the only things that needed to be different for an Alpha system are the motherboard and processor?
Yes. But things like cache memory are expensive, you know (IIRC Athlons have only 512K L2 cache).
And it seems the new motherboards are using AMD's 750 Athlon chipset now. So shouldn't the mobos be cheap, like under $300? Is the processor very expensive?
Unfortnately the mobo is different than those used for Athlon, and hasn't achieved the same economies of scale.
Is it possible to get a 21264 system with SCSI for under $3000?
Don't know about SCSI, but you can find a fully configured UP1100-based system for well under $3000. (Do you really need SCSI? You could always add it on later...)
About page coloring, this is something I heard freebsd does and not linux. myth or reality?
I don't know.
I heard the same. However I tried running lmbench on a XP1000 running Linux and FreeBSD; if page coloring is there the difference wasn't really noticeable. I'm still investigating though.
I still need to upgrade my box to patato and check-out ccc, but all in all, it looks like the
box will never run Tru64, then:-/
Note you can run some Tru64 apps on Linux anyway, with the tru64-compat package shipped with Red Hat.
I wasn't impressed by the speed of say... povray compiled with gcc, but with an alpha
compiler released by compaq, I should still see some improvement in my calculations...
Quite possibly. Isn't povray floating-point? GCC isn't very impressive on FP yet...
You ever tried to solve a 4000x4000 double float system? it's... slow. All I'm waiting for is a decent 4 to 8 SMP athlon box with 2Gb of memory.
Maybe. It helps when working with such code to understand your cache architecture and virtual memory. Tuning the algorithm to improve locality (and avoid processor stalls) can reap huge benefits. Chances are your working set is too large to fit in cache. Page coloring could help (if Linux supported it, that is).
If you want to try something interesting, profile your code with iprobe. That can tell you a lot about your code. Besides it's something your Intel-using friends can't do...
SMP may or may not be the answer. If your code chokes on main memory throughput, SMP will aggravate the problem.
The Ruffian was orphaned by Deskstation. It doesn't support SRM, ARC or AlphaBIOS, but it's very own ARCSBIOS. Fortunately, MILO is available so you can run Linux.
But since there is no SRM (and never will be) there is no hope of running either Tru64 or OpenVMS. Your choices are NT, Linux, and possibly NetBSD (if somebody ever hacks it to load from MILO, which is possible but nobody's done the work).
The Linux kernel has never been self-booting on Alpha. You are thinking of MILO, which is based loosely on the kernel sources and which provides BIOS emulation and PALcode for the kernel.
MILO itself is not self-booting. There was an experimental project to flash MILO, but it only worked on a few systems and was never supported.
ARC and AlphaBIOS are both history. They aren't available for new systems. SRM is now the preferred bootloader for Linux, and is available for most machines, old and new, except for a few systems that were designed for NT only.
Did you notice that Compaq freed up SRM? It used to require license fees but now it is freely downloadable on all hardware for which it is available.
Slashdot Mirror
They certainly did a lot of pimping of the word "innovation" during the anti-trust trial, but this seems to be genuinely innovative stuff to me.
It's not quite "innovative" in the sense that it hasn't been done before, but it certainly hasn't been done well. So if Microsoft really pulls it off it might quite rightly be a major coup.
There are related efforts in the free software community as well. The GCC project has implemented object-level compatibility between C++ and Java, for example. It's not quite seamless, and never can be owing to langauge differences. But it's a nice starting achievement, to which I hope other OO languages will be added in the future.
Actually there is a ring of truth to what bubbha is saying. I can provide a little technical background.
The Visual Basic language and runtime are historically single-threaded and event-driven. The Java language has been multithreaded from the start, yielding two distinct advantages for server programming:
The reason VB is not completely crippled by its lack of threads is a feature of COM known as a single-threaded apartment, or STA. This allows COM to marshal in-process requests to/from VB and other languages, even if the latter is multithreaded. Requests to an STA are queued on the Windows event queue, and are considerably slower than direct method invocations.
To achieve concurrency with VB components, one usually must instantiate a pool of components, dispatching each request to an available component. Microsoft Transaction Server (MTS) conveniently provides this capability. This is not without its drawbacks, for example separate VB components created this way cannot see each other's memory (or they would violate the single-threade constraint) so some other means is necessary to share state.
It is my understanding that a future release of VB will be multithreaded. That's not surprising except that it has been a long time coming. Part of the difficulty may have to do with COM itself, which implements automatic resource management with reference counting. The main advantage of reference counting is simplicity. Among the drawbacks are performance problems, especially with multithreading (the increment/decrement operations must be atomic, which cannot be done cheaply on x86.) Compare with a tracing collector which is found in many JVM's and is very well suited to multithreading.
I haven't yet studied Microsoft's CLR. It'll be interesting to see what they add to COM to get around its problems.
The fork has merged. EGCS is now GCC.
Doing this kind of parallelism extraction in the compiler just plain makes more sense than doing it on the chip (with SMT).
He was talking about the compiler. The fact is, with the vast majority of code achieving a high level of ILP with compiler technology is a extremely difficult problem with no easy solutions. GCC tries very hard to achieve ILP on RISC architectures too. The standard tricks are well-known, but not nearly good enough to keep 8 integer units busy. (In some cases it may be provably impossible.)
Even if IA-64 solves the ILP problem, there is still the memory latency barrier. For those reasons many (myself included) are not so optimistic about IA-64 performance in the long haul.
And it's also why RedHat is screwing over their users by sticking with gcc over SGI's (GPL'ed) IA-64 compiler
I have no doubt that SGI's compiler is better suited to IA-64 today, since the backend was written exclusively for that chip. GCC's goal of compiling for every hardware is still worthwhile.
Btw GCC is not "Cygnus' baby", it belongs to the FSF. And the FSF has specific rules concerning contributed code that have nothing to do with Red Hat.
GCC is a large, complex project of well over a half million lines of code and a complexity that can take months to master. Yet it stands as an exmaple of a large project with its origins in free software (unlike Mozilla).
Yet it steadily attracts contributors, most of whom tend to master small portions of the system leaving the rest to others.
Of course GCC has quite a bit of corporate sponsorship, which doesn't hurt any...
I've seen many young candidates with good technical experience lacking in business experience.
For what it's worth, managers tend to respect the latter.
Anyway, most of the "technical" jobs I've applied for (mostly in IT) were really business positions. When you have to write a scope of work or interview the customer, that's business. Sadly, there are relatively few opportunties available in pure computer science.
Not obvious. Servlets are among the fastest way to get dynamic content, capable of hundreds or even thousands of page generations per second from a single uniprocessor. Please prove your claim.
and also C# can use classes written in other languages which i found very interesting.(and java has yet to find a way to do it).
Incorrect. First, there exist compilers for numerous languages that translate to bytecode. Second there are interpreters like JPython and Jacl, if you want to marry scripts to your Java classes. Third, projects like gcj offer an alternative to pure Java that lets you easily marry Java/C++ code.
That's with 4MB external cache. Cache is expensive. $4k isn't unreasonable for any processor with 4MB.
Desktop computing does not significantly benefit from an alpha.
You might as well say "desktop computing does not significatly benefit from Linux." That would be no more or less true.
The fact is people run Linux because they want something different or better, or they are just bored with Microsoft OS's. For all of the same reasons, some prefer Alpha to x86.
If I have to pay 3x the hardware cost (Cheapest alphas I've been able to find start at $4.5K),
You haven't looked hard. New UP1100-based systems can be found for about half your figure. Good used equipment regularly shows up on Ebay for $1000 or less.
why wouldn't I run Tru64 with the DEC compilers since they won't release optimizations for GCC?
A few reasons spring to mind:
One could offer that RedHat has done an end-run around this issue with gcj
Many feel there ought to be a free Java. Kaffe is one, gcj is another, yet the free VMs haven't caught on, presumably because they lag behind the Sun releases (inevitably so).
but this technology is still somewhat flaky
Nothing flaky about gcj... it's just not released yet. (Ignoring the 2.95 release for a moment, 3.0 will be much more complete.) The code is about what you'd expect from a development snapshot.
and arguably if you aren't compiling to the JVM, you should probably be using C++ anyway.
You think the VM is the only benefit of Java? Regardless, gcj has a rather nice bytecode interpreter in its runtime, and offers a nice hybrid of bytecode with compiled core classes. You'd be surprised how well it performs without a JIT, especially the load time.
Although Linux does support console on the serial port, so if that "rack mount device" you speak of is a basic term-server/serial port switcher, you can manage your x86 Linux boxen the same damn way.
True, almost. Just hope you don't have to perform any BIOS changes from a serial console. You can't compare the poor excuse of firmware that ships with most PCs to OpenBoot.
The Blackdown Project has Sparc ports. 1.2.2 is available, though I don't believe that 1.3 is yet.
Good point. The Blackdown folks do fine work. But it's still no match for the Solaris 1.2.2 Production VM. Our server apps have to be robust, fast, robust, high performance, robust...
(I'm hoping the gcj project will become the great equalizer on Java performance, but it's not quite there yet.)
Chances are, if you have a Sparc machine, it drained at least $10,000 from your wallet and it's running Solaris 7/8.
So now who's making assumptions? We buy rack-mount SPARC hardware regularly, for general purpose servers. They are not Sun branded, they are built on OEM hardware, and can be purchased new for about $2300 and up.
It's easy to justify buying the SPARC hardware over x86:
Most of our SPARCs are running Solaris today. I'm considering installing Linux on some of those to simplify management: it's easer to manage a network of Linux machines than a mix of Linux and Solaris. The main criteria is whether we need a JVM... those running Java are stuck with Solaris for now.
Who do you call at 3:00 in the morning for technical support on your site????
You're kidding, right? Why is it that I have been unable to get quality support from Allaire for any price?
Keep your support contracts. I'll keep my open source. Fair enough?
Have you ever considered the reason you get little traffic? Couldn't be because of a sluggish site now, could it?
There is so much free and commercial Java and COM libraries available for JSP/Servlet and ASP or Cold Fusion developers, but not for PHP.
That's partly true. ColdFusion however tries to be portable, with availability on NT, Linux, Solaris, and others. COM certainly isn't available on all those platforms.
For that matter, when using PHP on Windows, you could write your own COM bindings... you have the source.
That is to say, the availability of COM isn't so much a language issue as a platform issue.
I think perl is actually better, but for true speed I'd use C.
Do you really want to spend half your debugging time chasing memory leaks and SIGSEGV traps? *shudder* There are far better choices than C for long-running server applications.
DON'T use tcl, or you will regret it.
So what's wrong with Tcl? AOLServer is actually quite capable, it'll hold its own against PHP etc.
Nice summary, I agree wholeheartedly.
Incidentally, our experience with ColdFusion is very similar; the scripts are difficult to debug and test, performance is miserable for any complex pages, and the server fails for reasons that are difficult to explain.
Many "features" of ColdFusion, i.e. memory management, are mostly undocumented and poorly understood. I have had CF scripts that exhaust server memory (yes, 1GB of memory) until I "tweaked" them slightly.
But is it really that more expensive? I thought the only things that needed to be different for an Alpha system are the motherboard and processor?
Yes. But things like cache memory are expensive, you know (IIRC Athlons have only 512K L2 cache).
And it seems the new motherboards are using AMD's 750 Athlon chipset now. So shouldn't the mobos be cheap, like under $300? Is the processor very expensive?
Unfortnately the mobo is different than those used for Athlon, and hasn't achieved the same economies of scale.
Is it possible to get a 21264 system with SCSI for under $3000?
Don't know about SCSI, but you can find a fully configured UP1100-based system for well under $3000. (Do you really need SCSI? You could always add it on later...)
About page coloring, this is something I heard freebsd does and not linux. myth or reality? I don't know.
I heard the same. However I tried running lmbench on a XP1000 running Linux and FreeBSD; if page coloring is there the difference wasn't really noticeable. I'm still investigating though.
Well, it worked on my 164LX board quite well.
You got lucky. But the LX is out of production, and flashing MILO doesn't work on current production Alpha mobo's.
I still need to upgrade my box to patato and check-out ccc, but all in all, it looks like the box will never run Tru64, then :-/
Note you can run some Tru64 apps on Linux anyway, with the tru64-compat package shipped with Red Hat.
I wasn't impressed by the speed of say... povray compiled with gcc, but with an alpha compiler released by compaq, I should still see some improvement in my calculations...
Quite possibly. Isn't povray floating-point? GCC isn't very impressive on FP yet...
You ever tried to solve a 4000x4000 double float system? it's... slow. All I'm waiting for is a decent 4 to 8 SMP athlon box with 2Gb of memory.
Maybe. It helps when working with such code to understand your cache architecture and virtual memory. Tuning the algorithm to improve locality (and avoid processor stalls) can reap huge benefits. Chances are your working set is too large to fit in cache. Page coloring could help (if Linux supported it, that is).
If you want to try something interesting, profile your code with iprobe. That can tell you a lot about your code. Besides it's something your Intel-using friends can't do...
SMP may or may not be the answer. If your code chokes on main memory throughput, SMP will aggravate the problem.
No chance, sorry.
The Ruffian was orphaned by Deskstation. It doesn't support SRM, ARC or AlphaBIOS, but it's very own ARCSBIOS. Fortunately, MILO is available so you can run Linux.
But since there is no SRM (and never will be) there is no hope of running either Tru64 or OpenVMS. Your choices are NT, Linux, and possibly NetBSD (if somebody ever hacks it to load from MILO, which is possible but nobody's done the work).
No.
The Linux kernel has never been self-booting on Alpha. You are thinking of MILO, which is based loosely on the kernel sources and which provides BIOS emulation and PALcode for the kernel.
MILO itself is not self-booting. There was an experimental project to flash MILO, but it only worked on a few systems and was never supported.
ARC and AlphaBIOS are both history. They aren't available for new systems. SRM is now the preferred bootloader for Linux, and is available for most machines, old and new, except for a few systems that were designed for NT only.
Did you notice that Compaq freed up SRM? It used to require license fees but now it is freely downloadable on all hardware for which it is available.
Yep. BTW you forgot to mention the Java applet that crashed my Netscape browser...