I had exactly the same thought too. I think it was in the article about blender being released as GPL. Anyway, doesn't change the fact that the original author is just another dimwit or a troll (or both).
There is the kroupware project, working to create software with exchange + outlook functionality for free. They're just getting started, but most of the stuff is just integrating existing stuff, so maybe in a year or so something this could seriously kick exchange ass.
Gas turbines in power stations are combined cycle, ie. they additionally have steam turbines using the excess heat from the gas turbines. This pushes up efficiency quite a lot, the best designs are about 60% efficient today. The best diesels are about 50-60%, and I find it hard to believe that a gas turbine without the steam turbine will get close to that.
Yeah, but adjust your release schedule according to which major package? As it stands now, many distros nudged their scheduled so they could release with gcc 3.2. While many desktop users may never touch the compiler, in this case it's important since gcc 3.2 has a different C++ ABI than previous versions.
Another point is that major releases of big projects tend to have quite a few bugs. If you wait a while you can use the bugfix releases, which inevitably follow any big release.
Apparently they're waiting for gcc 3.2 to be the default compiler before they upload kde 3 to unstable. As to what's holding gcc 3.2, go figure. I read somewhere that they're waiting for glibc 2.3, or was it the other way around.
Re:(Massively) parallel supercomputing
on
Ask Donald Becker
·
· Score: 2
None, really. Most large scientific applications are written using MPI (message passing). Both "high end" supercomputers and beowulf tend to be clusters these days. The difference is just that the high end stuff has bigger nodes and faster interconnects. And well, some supercomputers use vector processors, like the japanese, but they still use MPI for inter-node communication.
In addition to infiniband, as you said, there is arapahoe/3gio which as I understand it, is "serial PCI". It is also a switched architecture, as opposed to pci, which is shared.
Of course, neither of these will lessen the overhead of tcp/ip.
Re:Message Passing vs. Single System Image
on
Ask Donald Becker
·
· Score: 4, Insightful
Programming MPI (i.e. message-passing) is slow, difficult and error-prone. But I'd say making the hardware and especially the operating system for a single system image computer with thousands of processors is even more difficult. Or hey, why stop at thousands of processors? IBM is designing their Blue Gene computer, with 1 million processors. How do you make a single kernel scale on a system like that?
The traditional approach is to use fine grained locking in the kernel, but this tends to lead to unmaintainable code and low performance on lower end systems. For an example of this see Solaris, or most other big iron unix kernels.
Another approach is the OS cluster idea championed by Larry McVoy (the Bitkeeper guy). The idea is that you run many kernels on the same computer, one kernel takes care of something like 4-8 cpu:s. And then they cooperate somehow so they can give the impression of SSI.
A third approach seems to be the K42 exokernel project by IBM. They claim very good scalability without complicated lock hierarchies. The basic design idea seems to be to avoid global data whenever possible. Perhaps someone more knowledgeable might shed more light on this...
But anyway, until someone comes up with a kernel that scales to zillions of cpu:s, message passing is about the only way to go. Libraries the give you the illusion of using threads but are actually using message passing underneath might ease the pain somewhat, but for some reason they have not become popular. Perhaps there is too much overhead. And some people claim that giving the programmer the illusion that all memory access is equal speed leads to slow code. The same argument also applies to NUMA systems.
And on the system administration side of things, projects like mosix and bproc already today give you the impression of a single system image. Of course your application still has to use message passing, but administration and maintenance of a cluster is greatly simplified.
At moderate cost, the most popular are myrinet and dolphin, at around $1000-$1500 per node IIRC. For the high end stuff, there's quadrics, at $3000+ per node. Of course, quadrics is also mind-bogglingly fast, something like 350MB/s in each direction, and 5 us latency.
Beowulf, or rather bproc, has supported MPI for quite some time already. And if you don't want any single system image thing, MPI has been available for Linux for bloody ages. And I don't think it requires any kernel parts, so probably it would be quite easy to port to OSX.
I'm quite certain that when Donald Becker made the choice between Linux and *BSD (IF he ever really thought about it) there were no commercial fortran compilers for Linux either.
I don't know about the Leidenfrost effect, but drinking liquid nitrogen is absolutely not safe. There was a notice in New Scientist not long ago when some undergraduate tried this, and failed. He spent like 3 weeks in intensive care, and parts of his stomach had to be replaced, IIRC.
So yeah, it looks cool (yes I've seen it), but personally I'd rather be slightly less cool in the eyes of the audience and not risk spending a month in intensive care. Of course, YMMW.
That assumes you can divide the work equally. Consider that the number of source files probably aren't an integer*N, and that different source files take varying times to compile. Of course, as the number of source files approaches infinity, and if you have some load balancing scheme, this becomes a non-issue. Of course, in Real Life (TM) most projects don't have an infinite amount of source files.
The concept of universality has been an important concept in statistical physics for at least a few decades now.
And yes, scale-free networks are also a hot topic in statistical physics today. The point is, scale-free networks are characterized by common properties, just as universality classes are. So if you come to the conclusion that both the internet and human sexual networks are both scale-free, then e.g. attacks on certain types of nodes will have the same kind of effect.
C99 has complex numbers. But I agree the array syntax in F90 is extremely neat. F77 doesn't have that, so I don't really see why F77 arrays are any better than C ones.
Umm, could you elaborate on this? Do you mean some kind of COW (copy-on-write) kind of stuff (i.e. MVCC in database terminology). I.e. if you write to a locked resource, a new copy of the resource is created, and when the writing is completed and noone is reading the original resource the new one is copied over the old one? I think someone was experimenting with this for the Linux kernel, they came to the conclusion that for data structures which are mostly read-only this is faster than the traditional locking approach, but if you need to write a lot, this is slower because of the overhead of copying.
For those who have been following the Linux kernel development, there are two implementations trying to replace the current threads implementation, the NPTL (native posix thread library) by Ingo Molnar and Ulrich Drepper, and the NGPT (next generation posix threads) by IBM. The NPTL is a 1-1 implementation while NGPT is m-n. Based on some benchmarks it looks like NPTL is a lot faster and is being included in the 2.5 kernels (and glibc 2.3). Also, Solaris 9 has moved to a 1-1 thread implementation, so while a m-n thread implementation perhaps has some theoretical advantages it seems that it is so complex and has so much overhead that 1-1 is preferred.
And, as the AC above already said, the POSIX thread standard leaves the choice of 1-1 or m-n up to the implementor. Which is logical, since it doesn't change the semantics of the program using pthreads.
I'd say you have to get an awful lots of socks to exhaust the 128-bit address space in IPv6:) It works out to something like 5e28 addresses per human being.
Slashdot Mirror
Hah, I found it.
I had exactly the same thought too. I think it was in the article about blender being released as GPL. Anyway, doesn't change the fact that the original author is just another dimwit or a troll (or both).
There is the kroupware project, working to create software with exchange + outlook functionality for free. They're just getting started, but most of the stuff is just integrating existing stuff, so maybe in a year or so something this could seriously kick exchange ass.
I currenlty use the ACPI support included as default in the 2.4 kernels. You were saying...?
Gas turbines in power stations are combined cycle, ie. they additionally have steam turbines using the excess heat from the gas turbines. This pushes up efficiency quite a lot, the best designs are about 60% efficient today. The best diesels are about 50-60%, and I find it hard to believe that a gas turbine without the steam turbine will get close to that.
Yeah, but adjust your release schedule according to which major package? As it stands now, many distros nudged their scheduled so they could release with gcc 3.2. While many desktop users may never touch the compiler, in this case it's important since gcc 3.2 has a different C++ ABI than previous versions.
Another point is that major releases of big projects tend to have quite a few bugs. If you wait a while you can use the bugfix releases, which inevitably follow any big release.
Apparently they're waiting for gcc 3.2 to be the default compiler before they upload kde 3 to unstable. As to what's holding gcc 3.2, go figure. I read somewhere that they're waiting for glibc 2.3, or was it the other way around.
None, really. Most large scientific applications are written using MPI (message passing). Both "high end" supercomputers and beowulf tend to be clusters these days. The difference is just that the high end stuff has bigger nodes and faster interconnects. And well, some supercomputers use vector processors, like the japanese, but they still use MPI for inter-node communication.
And looking at US foreign policy, they seem to think Us == America == World. Sorry, couldn't resist.. :)
In addition to infiniband, as you said, there is arapahoe/3gio which as I understand it, is "serial PCI". It is also a switched architecture, as opposed to pci, which is shared.
Of course, neither of these will lessen the overhead of tcp/ip.
Programming MPI (i.e. message-passing) is slow, difficult and error-prone. But I'd say making the hardware and especially the operating system for a single system image computer with thousands of processors is even more difficult. Or hey, why stop at thousands of processors? IBM is designing their Blue Gene computer, with 1 million processors. How do you make a single kernel scale on a system like that?
The traditional approach is to use fine grained locking in the kernel, but this tends to lead to unmaintainable code and low performance on lower end systems. For an example of this see Solaris, or most other big iron unix kernels.
Another approach is the OS cluster idea championed by Larry McVoy (the Bitkeeper guy). The idea is that you run many kernels on the same computer, one kernel takes care of something like 4-8 cpu:s. And then they cooperate somehow so they can give the impression of SSI.
A third approach seems to be the K42 exokernel project by IBM. They claim very good scalability without complicated lock hierarchies. The basic design idea seems to be to avoid global data whenever possible. Perhaps someone more knowledgeable might shed more light on this...
But anyway, until someone comes up with a kernel that scales to zillions of cpu:s, message passing is about the only way to go. Libraries the give you the illusion of using threads but are actually using message passing underneath might ease the pain somewhat, but for some reason they have not become popular. Perhaps there is too much overhead. And some people claim that giving the programmer the illusion that all memory access is equal speed leads to slow code. The same argument also applies to NUMA systems.
And on the system administration side of things, projects like mosix and bproc already today give you the impression of a single system image. Of course your application still has to use message passing, but administration and maintenance of a cluster is greatly simplified.
At moderate cost, the most popular are myrinet and dolphin, at around $1000-$1500 per node IIRC. For the high end stuff, there's quadrics, at $3000+ per node. Of course, quadrics is also mind-bogglingly fast, something like 350MB/s in each direction, and 5 us latency.
Beowulf, or rather bproc, has supported MPI for quite some time already. And if you don't want any single system image thing, MPI has been available for Linux for bloody ages. And I don't think it requires any kernel parts, so probably it would be quite easy to port to OSX.
I'm quite certain that when Donald Becker made the choice between Linux and *BSD (IF he ever really thought about it) there were no commercial fortran compilers for Linux either.
I don't know about the Leidenfrost effect, but drinking liquid nitrogen is absolutely not safe. There was a notice in New Scientist not long ago when some undergraduate tried this, and failed. He spent like 3 weeks in intensive care, and parts of his stomach had to be replaced, IIRC.
So yeah, it looks cool (yes I've seen it), but personally I'd rather be slightly less cool in the eyes of the audience and not risk spending a month in intensive care. Of course, YMMW.
That assumes you can divide the work equally. Consider that the number of source files probably aren't an integer*N, and that different source files take varying times to compile. Of course, as the number of source files approaches infinity, and if you have some load balancing scheme, this becomes a non-issue. Of course, in Real Life (TM) most projects don't have an infinite amount of source files.
/usr/local/bin is as standard as /opt/kde. Read the FHS. /usr/local/kde, on the other hand, is everything but standard.
The concept of universality has been an important concept in statistical physics for at least a few decades now.
And yes, scale-free networks are also a hot topic in statistical physics today. The point is, scale-free networks are characterized by common properties, just as universality classes are. So if you come to the conclusion that both the internet and human sexual networks are both scale-free, then e.g. attacks on certain types of nodes will have the same kind of effect.
I see no fallacy here.
Actually, these days you grab the LAPACK routines instead of linpack. But if you like C++, MTL is about as fast as lapack.
C99 has complex numbers. But I agree the array syntax in F90 is extremely neat. F77 doesn't have that, so I don't really see why F77 arrays are any better than C ones.
Umm, could you elaborate on this? Do you mean some kind of COW (copy-on-write) kind of stuff (i.e. MVCC in database terminology). I.e. if you write to a locked resource, a new copy of the resource is created, and when the writing is completed and noone is reading the original resource the new one is copied over the old one? I think someone was experimenting with this for the Linux kernel, they came to the conclusion that for data structures which are mostly read-only this is faster than the traditional locking approach, but if you need to write a lot, this is slower because of the overhead of copying.
For those who have been following the Linux kernel development, there are two implementations trying to replace the current threads implementation, the NPTL (native posix thread library) by Ingo Molnar and Ulrich Drepper, and the NGPT (next generation posix threads) by IBM. The NPTL is a 1-1 implementation while NGPT is m-n. Based on some benchmarks it looks like NPTL is a lot faster and is being included in the 2.5 kernels (and glibc 2.3). Also, Solaris 9 has moved to a 1-1 thread implementation, so while a m-n thread implementation perhaps has some theoretical advantages it seems that it is so complex and has so much overhead that 1-1 is preferred.
And, as the AC above already said, the POSIX thread standard leaves the choice of 1-1 or m-n up to the implementor. Which is logical, since it doesn't change the semantics of the program using pthreads.
I'd say you have to get an awful lots of socks to exhaust the 128-bit address space in IPv6 :)
It works out to something like 5e28 addresses per human being.
people still use java?
http://www.biker-needs-a-harley.org
Bikers still want harleys? sheesh...
I think win XP supports IPv6. Of course it will be a while until a sizeable part of windows machines will be XP or newer.