"GNU TOOLS FOR LINUX: BECAUSE LINUX USERS HAVE A RIGHT TO CLEAN, ATTRACTIVE, EFFICIENT OBJECT ORIENTED CODE, TOO."
First GCJ is not for Linux only. Second compiling Java to native machine code does not guarantee performance improvements, and memory consumption could be even worse than for a JVM (I tried a famous object to native code compiler on NT, the memory consumption was at least twice as much for an application compared to just JVM).
Just like with any language Java code is not always clean and attractive. Java does not guarantee clean and attractive code. Nor does any other programming language.
<FLAME> And since when do object oriented and efficiency go together? Just look at Mozilla or KDE for example. Bloat, bloat, bloat. </FLAME>
Wake up. There's no privacy, democracy, or freedom as we know it. Everything is a joke. KGB, CIA, NSA and FBI have traditionally been above the law. They have the power and resources. We don't.
I actually had a chance to work in the NSTX control room with a test Appleseed cluster (as part of my co-op). It was fun. I think the reason they like Macs so much is very low maintenance. Also they've used them traditionally. I remember many had very old Macs in their offices. Too bad the Fortran code that ran so very well on Cray ran much slower on G3 350 Macs.
Actually, for this particular application (plasma physics) Ethernet is fine and well. The code is not so communication intensive at all. Appleseed could benefit from a better TCP/IP stack though.
I actually had a chance to run Aplleseed on an occasion. The Fortran application written for Cray was ported using Absoft F90 Fortran. Unoptimized, its performance was 1/3 that of an 21164 Alpha per processor per node. Those were G3 350 machines at the time. It was fun.
"uh, tux is a linux kernel http server...
a VERY STUPID IDEA..."
You obviously haven't even researched TUX to begin with. Typical BSD zealot.
CGI applications can be configured as user-level modules in TUX. TUX is _VERY_ safe AND stable. In fact just as safe as in-kernel firewalling. What, BSD doesn't have in-kernel firewalling or NFS because they introduce stability or security problems? Or that too, a "VERY STUPID IDEA"? Even OpenBSD has kernel space server code.
"why do you think IIS
has such fucked exploits?."
Because IIS was designed for a different OS (with all it's problems), is a very different server than TUX and has been written by a company that doesn't care about security among other reasons.
"many test that show that on OS's like the BSD's and linux, forking is actually a more efficient method than threading.."
Give me at least a single URL please.
"...if i had a heavy threading app on mulitple cpu's i would look
no further than solaris..."
There are many kinds of thread libraries out there (many not kernel-dependent), and you do not have to have an SMP machine to enjoy benefits of threading. Duplicating resources per every process is very expensive, not mentioning the terrible cost of process start and context switch compared to just a thread.
In fact take a look at http://oss.sgi.com/projects/state-threads.
Anyway going back to my original post, let's compare BSD and Linux running a SPED server like Zeus or something like a TUX server and see the results. Get your facts first before flaming.
You are talking from experience of running a _forking_ server. Let's try something like Zeus or Tux on FreeBSD and compare results to be fair. And what does "under stress" mean? You are not swapping "under stress", are you?
If you have problems with debugging deadlocks and other thread-related problems, I strongly recommend state-threads.
If you are struggling with the traditional thread libraries way of dealing with shared address space, State Threads could be the right choice for a threads library. State Threads were designed for server/client I/O intensive applications. The library is portable, scales extremely well on multi-processor machines, and locking is not necessary since it allows for private thread data natively (no mutexes and locks needed, everything is user-space also). The server.c that's shipped with this library is not your common multi-threaded application, very easy to understand and doesn't suffer from locks. It's GPLd. http://oss.sgi.com/projects/state-threads/
I know performance is not a primary focus of OpenBSD, but how does it compare when running I/O intensive tasks (preferrably multithreaded applications) to FreeBSD and Linux? Does it carry any scalability features like FreeBSD's kernel queues? Are there any highly scalable daemons in planning? Have there been any large installations of OpenBSD similar to Yahoo or Hotmail?
Judging by previous experiences, lies FUD and mind control it is very hard to assume that anything good can come out of opening Win32 source if it ever happens. I can't see MS simply opening their source without a catch. I think if this ever happens they'll accomplish several of their goals. Make a deal with government (and have no strings attached to them this way), so far it's been very blind (the fact that UCITA is even being considered is rediculous, and a good example). Their other goal is screw up you and everyone else like they've been doing so far. Remember what happened to Win 3.11 when 95 came out? If they'll open some 98 code, and government leaves them alone, that would be equivalent to opening win 3.11 code -- irellevant because of W2K and constantly changing APIs! Remember what happened when IBM tried to keep up with the API in OS/2? 98 will soon be history just like 3.11 is. I would rather like to see them open sourcing IE than any of their OSs. Would make more sense according to the trial too.
Call this flamebait, BUT as history showed before M$'s strength is in people's ignorance and lies. Average suit gives no damn about bugs in W2K or M$'s evil behavior. They like an idea of a braindamaged OS that doesn't require much brainstraining or administration. Reboot is always easier, even if it means hours of downtime, even if they don't know about the cause of the problem. Qoute "Real OS for real people". And M$'s propaganda machine makes it very easy to disgregard any second thoughts, and just buy into it, get the evil product and deploy their solutions no matter how much pain and suffering it will cause them in the end, afterall it's just an easy reboot, and it's "your" fault. This doesn't apply to every company of course, but MS wouldn't be so rich if their plan didn't work, would they? Let me tell you this, noone gives a rat's ass about bugs in MS products, they WILL use them anyway. Expect this begemoth be worth a trillion dollars after release of W2K. Expect huge demand for crappy OS for the next several years. Expect lines of people in front of CompUSA. 'nuff said. Expect Linux to be for traditional geek companies only and for geeks. Expect decrease of demand for proprietory *nix. Expect MS taking over web and 'net, expect more integration of crap into their crappy OS. Expect most people still not caring. Expect more MS-sponsored benchmarks. Expect Novell dying. IMHO Linux needs help in marketing and general awareness. What's done currently is really not enough. If you want to play with MS one on one, you need to have a product just as braindamaged as W2K. But that ain't happening, and probably doesn't need to happen. But the company will eventually eat itself because it will lose control, and we'll help it. It's just a matter of time. It happened to IBM, it happened to Intel, it will happen to Micros~1. If you go against change, change doesn't care, life goes on.
I actually had an honor of working with one of these clusters at a famous university Plasma Physics Lab. Several points here. Do not forget that the benchmarks advertized are for UCLA's particular gyrokynetic code done in F77. The gyrokinetic code usually doesn't require a lot of communication anyway, so for small clusters slow networking is not much of a problem. That is why Beowulf clusters are so suitable for problems where you don't have much inter-node traffic. Crays use very high bandwidth interconnects which are expensive and not needed for particle code like this. The difference is in code implementation and the CPU. Also Crays use Alpha as their processor, and Alphas are very good at FP intensive code, but they need a lot of code tweaking to squeeze all of the performance Alpha can give. Once the code runs great on an Alpha, put it on a different CPU and you have it crawling (and vice/versa). The lab that I worked for had Fortran 90 gyrokinetic code which was basically accomplishing the same thing as UCLA's, BUT it ran 3 times faster on a 400 MHz Alpha, than on G3 350 MHz using AppleSeed. Network-wise scaling it on G3s was not a big problem (small cluster, not much IP traffic), should note MacOS would be unresponsive during the benchmarks completely; while the code was running (all of CPU was devoted to it, and MacOS doesn't do preemtive multitasking). Surprizingly UCLA's code runs very nicely on G3, just as fast, or better than it does on an Alpha, that's why Macs are so suitable for them (besides plug-n-play Beowulf factor). So I think comparing their results to an archaic Cray is a nice way of attracting attention, but when it comes to details it's just another Beowulf. Put a different code that does well on Cray on it, and it's 2/3s slower per processor. Though I must say, that availability of this kind of software is great, since research facilities have tons of Macs and CPU cycles. This software also eliminates a need for *nix sysadmining, but it is costly. Fortran compilers are expensive, and so are Macs. If I would be building a cluster and didn't have Macs off hand, I would use cheap PC labor and Linux (though would still have to pay around a grand for F90 compiler per license:(). What *nix offers is compatibility, flexibility, and preemtive multitasking, and it allows to run several parallel jobs at a time. Traditionally Beowulf software was written for *nix, and so many MPI implementations and other essential software (like FFFTW and other math/scientific libraries) are available primarily for *nix, and would have to be ported to MacOS or any other OS.
Slashdot Mirror
"GNU TOOLS FOR LINUX: BECAUSE LINUX USERS HAVE A RIGHT TO CLEAN, ATTRACTIVE, EFFICIENT OBJECT ORIENTED CODE, TOO."
First GCJ is not for Linux only. Second compiling Java to native machine code does not guarantee performance improvements, and memory consumption could be even worse than for a JVM (I tried a famous object to native code compiler on NT, the memory consumption was at least twice as much for an application compared to just JVM).
Just like with any language Java code is not always clean and attractive. Java does not guarantee clean and attractive code. Nor does any other programming language.
<FLAME> And since when do object oriented and efficiency go together? Just look at Mozilla or KDE for example. Bloat, bloat, bloat. </FLAME>
Something like this could be accomplished with a bunch of replicated LDAP servers. LDAP IS perfect for authentication.
Wake up. There's no privacy, democracy, or freedom as we know it. Everything is a joke. KGB, CIA, NSA and FBI have traditionally been above the law. They have the power and resources. We don't.
You don't need a lot of bandwidth for plasma simulations. Just a lot of FPU horsepower.
I actually had a chance to work in the NSTX control room with a test Appleseed cluster (as part of my co-op). It was fun. I think the reason they like Macs so much is very low maintenance. Also they've used them traditionally. I remember many had very old Macs in their offices. Too bad the Fortran code that ran so very well on Cray ran much slower on G3 350 Macs.
Actually, for this particular application (plasma physics) Ethernet is fine and well. The code is not so communication intensive at all. Appleseed could benefit from a better TCP/IP stack though.
I actually had a chance to run Aplleseed on an occasion. The Fortran application written for Cray was ported using Absoft F90 Fortran. Unoptimized, its performance was 1/3 that of an 21164 Alpha per processor per node. Those were G3 350 machines at the time. It was fun.
"uh, tux is a linux kernel http server...
a VERY STUPID IDEA..."
You obviously haven't even researched TUX to begin with. Typical BSD zealot.
CGI applications can be configured as user-level modules in TUX. TUX is _VERY_ safe AND stable. In fact just as safe as in-kernel firewalling. What, BSD doesn't have in-kernel firewalling or NFS because they introduce stability or security problems? Or that too, a "VERY STUPID IDEA"? Even OpenBSD has kernel space server code.
"why do you think IIS
has such fucked exploits?."
Because IIS was designed for a different OS (with all it's problems), is a very different server than TUX and has been written by a company that doesn't care about security among other reasons.
"many test that show that on OS's like the BSD's and linux, forking is actually a more efficient method than threading.."
Give me at least a single URL please.
"...if i had a heavy threading app on mulitple cpu's i would look
no further than solaris..."
There are many kinds of thread libraries out there (many not kernel-dependent), and you do not have to have an SMP machine to enjoy benefits of threading. Duplicating resources per every process is very expensive, not mentioning the terrible cost of process start and context switch compared to just a thread.
In fact take a look at http://oss.sgi.com/projects/state-threads.
Anyway going back to my original post, let's compare BSD and Linux running a SPED server like Zeus or something like a TUX server and see the results. Get your facts first before flaming.
You are talking from experience of running a _forking_ server. Let's try something like Zeus or Tux on FreeBSD and compare results to be fair. And what does "under stress" mean? You are not swapping "under stress", are you?
Standards are badly needed, DJB has a nice plea here: http://cr.yp.to/compatibility.html
If you have problems with debugging deadlocks and other thread-related problems, I strongly recommend state-threads. If you are struggling with the traditional thread libraries way of dealing with shared address space, State Threads could be the right choice for a threads library. State Threads were designed for server/client I/O intensive applications. The library is portable, scales extremely well on multi-processor machines, and locking is not necessary since it allows for private thread data natively (no mutexes and locks needed, everything is user-space also). The server.c that's shipped with this library is not your common multi-threaded application, very easy to understand and doesn't suffer from locks. It's GPLd. http://oss.sgi.com/projects/state-threads/
I know performance is not a primary focus of OpenBSD, but how does it compare when running I/O intensive tasks (preferrably multithreaded applications) to FreeBSD and Linux? Does it carry any scalability features like FreeBSD's kernel queues? Are there any highly scalable daemons in planning? Have there been any large installations of OpenBSD similar to Yahoo or Hotmail?
If you think gcc is not enough, then get the damm source and hack it to suit your needs.
Judging by previous experiences, lies FUD and mind control it is very hard to assume that anything good can come out of opening Win32 source if it ever happens. I can't see MS simply opening their source without a catch. I think if this ever happens they'll accomplish several of their goals. Make a deal with government (and have no strings attached to them this way), so far it's been very blind (the fact that UCITA is even being considered is rediculous, and a good example). Their other goal is screw up you and everyone else like they've been doing so far. Remember what happened to Win 3.11 when 95 came out? If they'll open some 98 code, and government leaves them alone, that would be equivalent to opening win 3.11 code -- irellevant because of W2K and constantly changing APIs! Remember what happened when IBM tried to keep up with the API in OS/2? 98 will soon be history just like 3.11 is. I would rather like to see them open sourcing IE than any of their OSs. Would make more sense according to the trial too.
MS knows they will still make money, and the product will still sell like hot cakes with bugs or without.
Call this flamebait, BUT as history showed before M$'s strength is in people's ignorance and lies. Average suit gives no damn about bugs in W2K or M$'s evil behavior. They like an idea of a braindamaged OS that doesn't require much brainstraining or administration. Reboot is always easier, even if it means hours of downtime, even if they don't know about the cause of the problem. Qoute "Real OS for real people". And M$'s propaganda machine makes it very easy to disgregard any second thoughts, and just buy into it, get the evil product and deploy their solutions no matter how much pain and suffering it will cause them in the end, afterall it's just an easy reboot, and it's "your" fault. This doesn't apply to every company of course, but MS wouldn't be so rich if their plan didn't work, would they? Let me tell you this, noone gives a rat's ass about bugs in MS products, they WILL use them anyway. Expect this begemoth be worth a trillion dollars after release of W2K. Expect huge demand for crappy OS for the next several years. Expect lines of people in front of CompUSA. 'nuff said. Expect Linux to be for traditional geek companies only and for geeks. Expect decrease of demand for proprietory *nix. Expect MS taking over web and 'net, expect more integration of crap into their crappy OS. Expect most people still not caring. Expect more MS-sponsored benchmarks. Expect Novell dying. IMHO Linux needs help in marketing and general awareness. What's done currently is really not enough. If you want to play with MS one on one, you need to have a product just as braindamaged as W2K. But that ain't happening, and probably doesn't need to happen. But the company will eventually eat itself because it will lose control, and we'll help it. It's just a matter of time. It happened to IBM, it happened to Intel, it will happen to Micros~1. If you go against change, change doesn't care, life goes on.
Disregard all spelling mistakes.
I actually had an honor of working with one of these clusters at a famous university Plasma Physics Lab. Several points here. Do not forget that the benchmarks advertized are for UCLA's particular gyrokynetic code done in F77. The gyrokinetic code usually doesn't require a lot of communication anyway, so for small clusters slow networking is not much of a problem. That is why Beowulf clusters are so suitable for problems where you don't have much inter-node traffic. Crays use very high bandwidth interconnects which are expensive and not needed for particle code like this. The difference is in code implementation and the CPU. Also Crays use Alpha as their processor, and Alphas are very good at FP intensive code, but they need a lot of code tweaking to squeeze all of the performance Alpha can give. Once the code runs great on an Alpha, put it on a different CPU and you have it crawling (and vice/versa). The lab that I worked for had Fortran 90 gyrokinetic code which was basically accomplishing the same thing as UCLA's, BUT it ran 3 times faster on a 400 MHz Alpha, than on G3 350 MHz using AppleSeed. Network-wise scaling it on G3s was not a big problem (small cluster, not much IP traffic), should note MacOS would be unresponsive during the benchmarks completely; while the code was running (all of CPU was devoted to it, and MacOS doesn't do preemtive multitasking). Surprizingly UCLA's code runs very nicely on G3, just as fast, or better than it does on an Alpha, that's why Macs are so suitable for them (besides plug-n-play Beowulf factor). So I think comparing their results to an archaic Cray is a nice way of attracting attention, but when it comes to details it's just another Beowulf. Put a different code that does well on Cray on it, and it's 2/3s slower per processor. Though I must say, that availability of this kind of software is great, since research facilities have tons of Macs and CPU cycles. This software also eliminates a need for *nix sysadmining, but it is costly. Fortran compilers are expensive, and so are Macs. If I would be building a cluster and didn't have Macs off hand, I would use cheap PC labor and Linux (though would still have to pay around a grand for F90 compiler per license :(). What *nix offers is compatibility, flexibility, and preemtive multitasking, and it allows to run several parallel jobs at a time. Traditionally Beowulf software was written for *nix, and so many MPI implementations and other essential software (like FFFTW and other math/scientific libraries) are available primarily for *nix, and would have to be ported to MacOS or any other OS.