The key word here is adequetely. With a mac, it can be performed well. Infact, all the basic tools are included with the system, not only Photo, but video, DVD production, music production, all part of the basic tool set.
Yes... and Microsoft got sued already for including too many things with the standard OS install. They are damned if they do and damned if they don't. Include too much you get sued for making it hard for someone else to write something for your OS (see Netscape). Include too little and you get folks like you saying how much better PlatformX is that all this is included.
Basically, all of the arguments in this thread are that "Mac is superior because it doesn't get worms/virii like Windows does". Well... it does, we've already seen some. It just isn't worth the time of a virus writer to target such a minority of the market. If/As Apple gets more market share, we'll see more, guaranteed.
Actually, it's why almost all government purchases in the USA are bid out. It's to keep someone from getting into office and ordering that only Product-X be bought. If you look through history, you'll find instances where government officials who owned things like brick companies ended up having their brick company getting all the contracts for roads being built while that official was in office.
Technically, the government isn't supposed to compete with commercial enterprise either. If the government is funding a project that eventually has a commercial alternative, the government is supposed to stop the funding. This is to prevent the government from driving companies out of business by subsidizing a competitor. However, this isn't enforced very often as evidenced by much of the stuff that comes out of government labs. Most commercial enterprises are very reluctant to push the issue as well because some government official's pet project losing funding generates lots of bad karma in the government.
Actually, the government of any reasonable country shouldn't be able to dictate what vendor provides software (whether proprietary or F/OSS) because it is overstepping its bounds. I have no problem with the goverenment dictating what standard document formats and such are required to interoperate, but in no way should they dictate what products are used to generate such documents. It should be up to the individual organizations (state/local governments and such) as to what they use. To me, they shouldn't be able to dictate Microsoft software or F/OSS or any OS either.
Well... if you have someone who knows what they are doing root your system, you may not know it for months. We had a machine that had been rooted for who knows how long and the only reason we knew it (we watch network traffic and such) was that the guy who rooted it got careless after a long time and did something that we noticed.
Similarly, my home machine got rooted when it was serving as the firewall to my home network. I noticed that it was running at 100% CPU when it shouldn't have been doing anything.
Because Linux and Unix do well isolating users from other users and such and is pretty stable, it's actually pretty easy for someone to do something that goes unnoticed for a long time.
With Windows, at least, we get some warning signs pretty fast - machine starts crashing, becomes sluggish, etc. Not that I'm saying that this is a good thing other than it helps detect when things are abnormally wrong.
"C++" effectively would do the EXACT SAME THING except with less control over the actual implementation.
Yup, the only (potential) difference is that a bunch of the stuff you have to do manually in C (table driven system, for example) will be done by the compiler for you in C++ (vtable).
The only real discussion point here is that the "less control over the actual implementation" means that in C, you are writing what C++ does for you in a number of cases. Not all of it complex, but maintaining your table by hand is more error prone than trusting the compiler to do it for you in some cases.
As I said before, I've had to use C for the past year or so on a project (no choice) and many of the things I've implemented are just things that C++ does for you automagically, basically exactly the same things that you're talking about. before that, I worked for five years on a similar system written in C but basically reimplementing stuff that C++ does for you because the writers all "knew" that C++ was evil (mostly due to some bad experiences they had because they didn't know enough about C++ do avoid some of the common performance mistakes and they had used C++ back when it was relatively new and was still sorta buggy and kludgy). That didn't stop them from implementing exactly what C++ does for you though. They just felt more secure doing it all by hand rather than letting the compiler do it for them./shrug
Yeah, who wants a common driver API for video, network, or sound cards...
I don't understand why a common driver API is not possible to do in C... Would you care explaining?
I didn't mention anything about choice of language. The OP didn't either.
Not to mention that drivers are all about abstracting the hardware and interface implementation from the OS itself anyway...
Does that mean we should give up on transparency?
No, but I fail to see why the kernel would have to see into the details of how a device driver is implemented. As long as it conforms to a well defined interface, it shouldn't care at all how it is implemented.
You can do some pretty neat things in C++ if you know what you are doing. If you don't know what you are doing, you can do some pretty crappy things.
This (again) begs the question: what can you do in C++ that you can not do in C? Is it just because classes, objects, constructors, destructors, inheritance, and all that crappy OOP stuff is specificly declared that C++ is that superior? You can do pretty well the same in C! There is absolutely no consistent technical reason supporting the use of C++ in the Linux kernel!
Quoting the FAQ [kernel.org] that you should indeed read since there are some Linus quotes there:
I agree with that quote but it has nothing to do with the fact that Linus said it. (And it doesn't "beg the question" because that phrase means something else.)
I've written OO code in C for the past 17 years or so as well as programmed in C++, Java, and C# (more recently) among other lesser known languages. I'm fully aware that I can do in C what C++ does, it just may take a bit more coding on my part to do some of the things. In fact, early C++ compilers were just manglers that output mangled C and compiled that for your program. With newer C++ standards, it isn't that easy anymore, though. Anyway, just as it was said in the quote that you posted, it isn't important what language you use, so what's with the beef against C++?
So.... what exactly is this site about other than having some pics of gothgirls on it? You seem to be a guy, so is the site really just a bunch of guys who link their favorite goth-pr0n pics or something?
I looked for a few minutes and couldn't figure it out more than that.
In other words, put the efforts where they're most needed.
I thought F/OSS (and Linux) was all about innovation and exploration... Sure, there are lots of things that F/OSS projects need (not the least of which is some QA effort), but it also needs folks like these people who are out doing cool stuff, even if it isn't necessary practical (or even considered practical by the 'masses' or the 'powers that be').
In a kernel, all the code needs to be transparent, and you definitely don't want to hide implementation and the usual abstractions.
Yeah, who wants a common driver API for video, network, or sound cards...
Not to mention that drivers are all about abstracting the hardware and interface implementation from the OS itself anyway...
The simple reason for that is that otherwise the kernel would be unpredictable. Let's say the error logging function used the string class (which likes to allocate memory behind your back). If the memory allocation function fails and tries to print an error message... you got yourself a kernel crash. This is why the kernel is significantly more difficult to program than, say, a word processor.
Yes, a kernel is more difficult than a word processor, but that doesn't mean that implementors must implement stupid C++ code. You can do some pretty neat things in C++ if you know what you are doing. If you don't know what you are doing, you can do some pretty crappy things.
LINPACK is not trivially parallel, so if you took a whole lot of computers and banged them together over Ethernet, all you'd end up with is an expensive way to keep your network busy.
True, but LINPACK is not exactly taxing on a system either, that is why there are clusters listed fairly high in the Top500 (some of them actually *with* Ethernet). There is a bit of communication that goes on, but not enough to really destroy clusters in communication overhead which is what makes supercomputers shine.
is coded in straight MPI. Each node has a stripped down linux kernel with no paging support and no forking.....bare minimum kernel that runs in RAM only
Yeah, this was the idea behind the CPlant at Sandia some time back. Each node was an Alpha box with like 1G of memory, but only 256M was made available to Linux directly. The rest was a big block of contiguous memory with only very simple services (no paging, etc. but it did have 'pipes' for IO like HDD access, network access, services for IO (printf and such) and the like. When a 'parallel app' was run, it existed in this memory block and ran outside of Linux's sheparding for the most part. It had direct access to the high speed networks (Myrinet) and such without much/any OS overhead.
Doing this, they had the flexibility of running Linux on each node for network services (netboot, ftp, ssh, etc) but had the benefits of having basically dedicated hardware with a custom OS (not Linux) that had a minimum of overhead for computational processes all on one node and running simultaneously. Very cool stuff.
The AMC Gremlin was a sleeper too. It is ugly and very unassuming until you realize that you could order them stock with 390 cu. in. engines in them. Do a little work on that engine and you can get 500 hp or so out of it. Not bad for a car that, like your Pinto above, weighed practically nothing.
Another car I've seen beefed up is a Maverick, same reasons, etc.
When I'm solving problems (of any kind) the OS is only one piece of the solution. I could care less if the OS is the most spiffy thing on the planet if the compilers used to generate executables for my work are horribly slow. My overall solution is slow in this case.
For server type tasks (file serving, web serving, and things like that) I have found the gap to be very narrow on the same hardware. Usually what wins out for me for Linux is the control I have over the system. I tend to use Linux boxes for web servers and the like because they do these things well because the tools available for doing these things are good. The OS itself is only a part of that solution.
The reason is this.. more and more of these 'supercomputer' entries appear to be many machines hooked up together, possibly doing a distributed calculation.
However, would projects such as SETI, GRID, and UD qualify with their many thousands of computers all hooked up and performing a distributed calculation ?
If not, then what about the WETA/Pixar/ILM/Digital Domain/Blur/You-name-it renderfarms ? Any one machine on those renderfarms could be put to use for only a single purpose: to render a movie sequence. Any one machine could be working on a single frame of that sequence. Does that count ?
Yes, all of these mentioned belong to a class of supercomputer applications called "Embarassingly Parallel". These types of algorithms are (by far) the easiest to implement since their calculations don't depend on anything being calculated by other nodes in the system. They are characterized by minimal/no communication among nodes (many times, just the communication to hand the node the data on which it is to compute and then one communication at the end to submit the results back to the central node) and lots of compute resources working on the local data. So, they *are* supercomputing of a type, just one that isn't that interesting from a computer science point of view.
There are many problems that require much more communication between the nodes. Calculations performed by one node is dependent upon the results generated by other nodes in the system. Some known solutions require so much communication/synchronization between nodes that it isn't practical to parallelize the problem and a serial solution is more optimal. There has been lots of work on various problems creating algorithms that are more "parallel friendly" in order to speed the solutions. There are some problems that have prizes for someone who can invent a way to make them more parallel.
Anyway, there are many "grains" of parallel computing. The "granularity" of a problem is the ratio of the amount of communication required per computation of the solution algorithm. Coarse grained problems are problems that have low communication/computation requirements. Embarassingly parallel problems are an example of this. The amount of communication required by a distributed node running SETI@HOME is very tiny compared to the amount of computation required for each WU. The same can be said for a render farm. Each node in a render farm receives the image to be rendered, then goes off for a while and renders that frame of the movie and hands the result back to the coordinator, which gives the node the next frame to render. Fine grained problems are the other side of the spectrum and require more communication for each computation operation. Solutions to systems of equations are an example. A problem that has to communicate its results to each of its "neighbors" and receive the results from each of its neighbors on each iteration so that the next iteration can be calculated is more finely grained.
Beowulf clusters, with their slow interconnects, are good at solving coarse grained problems. Other systems, like the new Cray with the high bandwidth, low latency interconnects, work better for fine grained problems. In a fine grained problem, a machine with "slow" processors but a fast interconnect may outperform a Beowulf type cluster that has the fastest commodity CPUs available but a slow interconnect.
By the way, LINPack (the benchmark used for the Top500) is a rather coarse grained problem. That's why Beowulf style clusters appear in the list. There are plenty of other benchmarks that could be used where these clusters would have a hard time.
Many of these systems are loss-leaders for the companies involved. The manufacturor (in this case Apple) weighs the benefit of the publicity (advertising) generated by such an endeavor against the actual cost to see if it is worth it. It should be quite easy to verify the amount of discount by just getting the prices from the Apple Store and doing the educational discount. Then factor in some labor costs as well.
This is much like the Munich Linux migration story. The costs that are quoted by Munich don't include the time (cost, salary) of many, many (possibly 100s) of techs that IBM is donating to the project to insure its success. If you add in all of the labor that is "free", the cost would go up quite a bit.
Depends on the site and their main focus. The Earth Simulator in Japan (#1 on the list) for example, is used to simulate and predict weather. Various machines at some of the national labs in the USA are used to simulate nuclear events. Some other machines in the biotech industries are used to do protien folding and things like attempting to simulate a human cell. Financial institutions use them to attempt to predict the economy, the stock market, and the like. Automobile manufacturors use them to simulate crash tests. Aeronautic firms use them to simulate new vehicles.
In the past, there has been talk about companies that exist solely to supply compute power. Such a company would have a warehouse full of computers and control them through schedulers (batch, etc.) and sell time on the machines to anyone who wanted it. So far, I don't think anyone has been successful with the idea yet.
Re:Just the name brings back memories
on
Cray XT-3 Ships
·
· Score: 1
I dunno... many of the HPC machines I've seen use batch schedulers and do, in fact, run at near 100% CPU utilization for weeks on end. When you have 1000s of scientists from all over the world all queuing up jobs to be run and each job takes a while, the machine tends to stay busy. We even had jobs that took multiple days to run even when running on 64+ CPUs (all of them busy at 100% for as long).
Many of these machines at the national labs (Sandia, ORNL, WES, etc.) are actually used by scientists all over the USA, if not the world, so it isn't like the machine only runs the jobs that the folks at the site need run.
I've found just the opposite to be true. I've almost invaribly seen Linux run faster and more reliably than Windows on the same hardware.
I have *invariably* (no "almost" qualification) seen Windows run faster than Linux on the same exact hardware, and I've seen Linux/Windows run on the exact same hardware on 100s of machines.
Mostly, this is due to how crappy gcc was in the past as producing fast code. For example, We had a PPro 200 box (yea, this was a while back) that dual booted Windows and Linux. We also had an Intergraph TD dual Pentium 133. Both had like 512M memory (a huge amount back then). Some guys had some code they had written on Linux and asked me to quick port it to Windows and benchmark it for them for a paper so I did. After I ported it and sent them the results (never having seen the Linux results), they sent me email back saying I had messed up something, like maybe the routines to get the time stamps for comparison for execution. I checked it out a bunch and could find no problem with them and they produced accurate results. The problem was that the Windows code was performing 2X or more faster than their gcc compiled code. So, they brought their machine over (was exactly the same hardware as ours) and installed a dual boot Windows on it and we ran the tests on the two OSs on *their* hardware for both Windows and Linux. Sure enough, 2X or better on FPU intensive code. To make matters worse, our Pentium 133s running Windows outperformed their PPro 200 on some of their benchmarks. However, since then, gcc has gotten a lot better. It still isn't as good most of the time, but it isn't nearly as bad as it was.
Reliably on the same hardware is another story... But... I've seen some very reliable Windows hardware in the past as well.
All that being said, I've been working for the past year as a 100% Linux developer and my background before that Windows stuff was on Solaris and Irix 100%.
Only for immediate data. Most data will reside in memory locations and/or registers. The op code (and operand) size for these operations shouldn't be any larger than the ones for 32-bit values.
Examples: add r1,r2,r3// should be the same size regardless of the size of the data manipulated load r1, (r7)// same
Immeditates will possibly be effected, depending on whether the opcodes exist to use the smaller immediates.
Examples: load r1, #1// should be opcodes smart enough to load this value (1) using a small number of bits add r1, #256// same
This isn't anything new... a good compiler can/will rearrange loops and such so that it initiates fetches for the n+1 iteration during the nth iteration (this is regardless of platform). Other CPUs in the past had special instructions that were specifically designed to initiate memory reads in order to load the caches (L1 and/or L2) without actually doing anything with the data being loaded (not actually put it in any register, for example) simply so it will be in cache when it is needed.
Transactional buses are good for other things, though (more so than preloading data, as mentioned here).
I don't know of any FPU made in the last 20 years that have to break 64-bit FPU up into 32-bit operations. They make take longer (FPU optimized for 32-bit operations so 64-bit take a few cycles longer) but they are still handled natively.
The previous poster was talking about 32-bit and 64-bit integer values.
VS.NET runs great for me on WinXP. What kind of system do you have? If you have less than 512M memory, upgrade.
Also, don't do like one site I was at did... they had/have a bunch of P4 Celerons (1.5GHz Willies) running on PC133 memory... that's just horrible to begin with before actually trying to do any work.
I'm not sure why everyone insists on confusing the matter by using base 10 prefixes when there are base 2 prefixes available that are unambiguous.
Because we were using those prefixes in the computer world long before most of you were born and think it's quite rude for you folks to come along and try to change our vocabulary for us. Contrary to what you folks seem to think, WE know exactly what we are talking about, it's you folks who seem to have a problem understanding it and make up these rediculous sounding prefixes to "fix" a problem that doesn't exist other than through your own issues.
Slashdot Mirror
The key word here is adequetely. With a mac, it can be performed well. Infact, all the basic tools are included with the system, not only Photo, but video, DVD production, music production, all part of the basic tool set.
Yes... and Microsoft got sued already for including too many things with the standard OS install. They are damned if they do and damned if they don't. Include too much you get sued for making it hard for someone else to write something for your OS (see Netscape). Include too little and you get folks like you saying how much better PlatformX is that all this is included.
Basically, all of the arguments in this thread are that "Mac is superior because it doesn't get worms/virii like Windows does". Well... it does, we've already seen some. It just isn't worth the time of a virus writer to target such a minority of the market. If/As Apple gets more market share, we'll see more, guaranteed.
Actually, it's why almost all government purchases in the USA are bid out. It's to keep someone from getting into office and ordering that only Product-X be bought. If you look through history, you'll find instances where government officials who owned things like brick companies ended up having their brick company getting all the contracts for roads being built while that official was in office.
Technically, the government isn't supposed to compete with commercial enterprise either. If the government is funding a project that eventually has a commercial alternative, the government is supposed to stop the funding. This is to prevent the government from driving companies out of business by subsidizing a competitor. However, this isn't enforced very often as evidenced by much of the stuff that comes out of government labs. Most commercial enterprises are very reluctant to push the issue as well because some government official's pet project losing funding generates lots of bad karma in the government.
Actually, the government of any reasonable country shouldn't be able to dictate what vendor provides software (whether proprietary or F/OSS) because it is overstepping its bounds. I have no problem with the goverenment dictating what standard document formats and such are required to interoperate, but in no way should they dictate what products are used to generate such documents. It should be up to the individual organizations (state/local governments and such) as to what they use. To me, they shouldn't be able to dictate Microsoft software or F/OSS or any OS either.
Well... if you have someone who knows what they are doing root your system, you may not know it for months. We had a machine that had been rooted for who knows how long and the only reason we knew it (we watch network traffic and such) was that the guy who rooted it got careless after a long time and did something that we noticed.
Similarly, my home machine got rooted when it was serving as the firewall to my home network. I noticed that it was running at 100% CPU when it shouldn't have been doing anything.
Because Linux and Unix do well isolating users from other users and such and is pretty stable, it's actually pretty easy for someone to do something that goes unnoticed for a long time.
With Windows, at least, we get some warning signs pretty fast - machine starts crashing, becomes sluggish, etc. Not that I'm saying that this is a good thing other than it helps detect when things are abnormally wrong.
"C++" effectively would do the EXACT SAME THING except with less control over the actual implementation.
/shrug
Yup, the only (potential) difference is that a bunch of the stuff you have to do manually in C (table driven system, for example) will be done by the compiler for you in C++ (vtable).
The only real discussion point here is that the "less control over the actual implementation" means that in C, you are writing what C++ does for you in a number of cases. Not all of it complex, but maintaining your table by hand is more error prone than trusting the compiler to do it for you in some cases.
As I said before, I've had to use C for the past year or so on a project (no choice) and many of the things I've implemented are just things that C++ does for you automagically, basically exactly the same things that you're talking about. before that, I worked for five years on a similar system written in C but basically reimplementing stuff that C++ does for you because the writers all "knew" that C++ was evil (mostly due to some bad experiences they had because they didn't know enough about C++ do avoid some of the common performance mistakes and they had used C++ back when it was relatively new and was still sorta buggy and kludgy). That didn't stop them from implementing exactly what C++ does for you though. They just felt more secure doing it all by hand rather than letting the compiler do it for them.
Correction, the OP mentioned C++ in the statement but in reference to common APIs and such that I inferred as I posted.
Yeah, who wants a common driver API for video, network, or sound cards...
I don't understand why a common driver API is not possible to do in C... Would you care explaining?
I didn't mention anything about choice of language. The OP didn't either.
Not to mention that drivers are all about abstracting the hardware and interface implementation from the OS itself anyway...
Does that mean we should give up on transparency?
No, but I fail to see why the kernel would have to see into the details of how a device driver is implemented. As long as it conforms to a well defined interface, it shouldn't care at all how it is implemented.
You can do some pretty neat things in C++ if you know what you are doing. If you don't know what you are doing, you can do some pretty crappy things.
This (again) begs the question: what can you do in C++ that you can not do in C? Is it just because classes, objects, constructors, destructors, inheritance, and all that crappy OOP stuff is specificly declared that C++ is that superior? You can do pretty well the same in C! There is absolutely no consistent technical reason supporting the use of C++ in the Linux kernel!
Quoting the FAQ [kernel.org] that you should indeed read since there are some Linus quotes there:
I agree with that quote but it has nothing to do with the fact that Linus said it. (And it doesn't "beg the question" because that phrase means something else.)
I've written OO code in C for the past 17 years or so as well as programmed in C++, Java, and C# (more recently) among other lesser known languages. I'm fully aware that I can do in C what C++ does, it just may take a bit more coding on my part to do some of the things. In fact, early C++ compilers were just manglers that output mangled C and compiled that for your program. With newer C++ standards, it isn't that easy anymore, though. Anyway, just as it was said in the quote that you posted, it isn't important what language you use, so what's with the beef against C++?
So.... what exactly is this site about other than having some pics of gothgirls on it? You seem to be a guy, so is the site really just a bunch of guys who link their favorite goth-pr0n pics or something?
I looked for a few minutes and couldn't figure it out more than that.
I thought it was the SWG:WSSN - Will Stop Sucking Now - expansion pack...
In other words, put the efforts where they're most needed.
I thought F/OSS (and Linux) was all about innovation and exploration... Sure, there are lots of things that F/OSS projects need (not the least of which is some QA effort), but it also needs folks like these people who are out doing cool stuff, even if it isn't necessary practical (or even considered practical by the 'masses' or the 'powers that be').
In a kernel, all the code needs to be transparent, and you definitely don't want to hide implementation and the usual abstractions.
Yeah, who wants a common driver API for video, network, or sound cards...
Not to mention that drivers are all about abstracting the hardware and interface implementation from the OS itself anyway...
The simple reason for that is that otherwise the kernel would be unpredictable. Let's say the error logging function used the string class (which likes to allocate memory behind your back). If the memory allocation function fails and tries to print an error message... you got yourself a kernel crash. This is why the kernel is significantly more difficult to program than, say, a word processor.
Yes, a kernel is more difficult than a word processor, but that doesn't mean that implementors must implement stupid C++ code. You can do some pretty neat things in C++ if you know what you are doing. If you don't know what you are doing, you can do some pretty crappy things.
LINPACK is not trivially parallel, so if you took a whole lot of computers and banged them together over Ethernet, all you'd end up with is an expensive way to keep your network busy.
True, but LINPACK is not exactly taxing on a system either, that is why there are clusters listed fairly high in the Top500 (some of them actually *with* Ethernet). There is a bit of communication that goes on, but not enough to really destroy clusters in communication overhead which is what makes supercomputers shine.
is coded in
straight MPI. Each node has a stripped down linux kernel with no paging support and no forking.....bare minimum kernel that runs in RAM only
Yeah, this was the idea behind the CPlant at Sandia some time back. Each node was an Alpha box with like 1G of memory, but only 256M was made available to Linux directly. The rest was a big block of contiguous memory with only very simple services (no paging, etc. but it did have 'pipes' for IO like HDD access, network access, services for IO (printf and such) and the like. When a 'parallel app' was run, it existed in this memory block and ran outside of Linux's sheparding for the most part. It had direct access to the high speed networks (Myrinet) and such without much/any OS overhead.
Doing this, they had the flexibility of running Linux on each node for network services (netboot, ftp, ssh, etc) but had the benefits of having basically dedicated hardware with a custom OS (not Linux) that had a minimum of overhead for computational processes all on one node and running simultaneously. Very cool stuff.
The AMC Gremlin was a sleeper too. It is ugly and very unassuming until you realize that you could order them stock with 390 cu. in. engines in them. Do a little work on that engine and you can get 500 hp or so out of it. Not bad for a car that, like your Pinto above, weighed practically nothing.
Another car I've seen beefed up is a Maverick, same reasons, etc.
When I'm solving problems (of any kind) the OS is only one piece of the solution. I could care less if the OS is the most spiffy thing on the planet if the compilers used to generate executables for my work are horribly slow. My overall solution is slow in this case.
For server type tasks (file serving, web serving, and things like that) I have found the gap to be very narrow on the same hardware. Usually what wins out for me for Linux is the control I have over the system. I tend to use Linux boxes for web servers and the like because they do these things well because the tools available for doing these things are good. The OS itself is only a part of that solution.
The reason is this.. more and more of these 'supercomputer' entries appear to be many machines hooked up together, possibly doing a distributed calculation.
However, would projects such as SETI, GRID, and UD qualify with their many thousands of computers all hooked up and performing a distributed calculation ?
If not, then what about the WETA/Pixar/ILM/Digital Domain/Blur/You-name-it renderfarms ? Any one machine on those renderfarms could be put to use for only a single purpose: to render a movie sequence. Any one machine could be working on a single frame of that sequence. Does that count ?
Yes, all of these mentioned belong to a class of supercomputer applications called "Embarassingly Parallel". These types of algorithms are (by far) the easiest to implement since their calculations don't depend on anything being calculated by other nodes in the system. They are characterized by minimal/no communication among nodes (many times, just the communication to hand the node the data on which it is to compute and then one communication at the end to submit the results back to the central node) and lots of compute resources working on the local data. So, they *are* supercomputing of a type, just one that isn't that interesting from a computer science point of view.
There are many problems that require much more communication between the nodes. Calculations performed by one node is dependent upon the results generated by other nodes in the system. Some known solutions require so much communication/synchronization between nodes that it isn't practical to parallelize the problem and a serial solution is more optimal. There has been lots of work on various problems creating algorithms that are more "parallel friendly" in order to speed the solutions. There are some problems that have prizes for someone who can invent a way to make them more parallel.
Anyway, there are many "grains" of parallel computing. The "granularity" of a problem is the ratio of the amount of communication required per computation of the solution algorithm. Coarse grained problems are problems that have low communication/computation requirements. Embarassingly parallel problems are an example of this. The amount of communication required by a distributed node running SETI@HOME is very tiny compared to the amount of computation required for each WU. The same can be said for a render farm. Each node in a render farm receives the image to be rendered, then goes off for a while and renders that frame of the movie and hands the result back to the coordinator, which gives the node the next frame to render. Fine grained problems are the other side of the spectrum and require more communication for each computation operation. Solutions to systems of equations are an example. A problem that has to communicate its results to each of its "neighbors" and receive the results from each of its neighbors on each iteration so that the next iteration can be calculated is more finely grained.
Beowulf clusters, with their slow interconnects, are good at solving coarse grained problems. Other systems, like the new Cray with the high bandwidth, low latency interconnects, work better for fine grained problems. In a fine grained problem, a machine with "slow" processors but a fast interconnect may outperform a Beowulf type cluster that has the fastest commodity CPUs available but a slow interconnect.
By the way, LINPack (the benchmark used for the Top500) is a rather coarse grained problem. That's why Beowulf style clusters appear in the list. There are plenty of other benchmarks that could be used where these clusters would have a hard time.
Many of these systems are loss-leaders for the companies involved. The manufacturor (in this case Apple) weighs the benefit of the publicity (advertising) generated by such an endeavor against the actual cost to see if it is worth it. It should be quite easy to verify the amount of discount by just getting the prices from the Apple Store and doing the educational discount. Then factor in some labor costs as well.
This is much like the Munich Linux migration story. The costs that are quoted by Munich don't include the time (cost, salary) of many, many (possibly 100s) of techs that IBM is donating to the project to insure its success. If you add in all of the labor that is "free", the cost would go up quite a bit.
Depends on the site and their main focus. The Earth Simulator in Japan (#1 on the list) for example, is used to simulate and predict weather. Various machines at some of the national labs in the USA are used to simulate nuclear events. Some other machines in the biotech industries are used to do protien folding and things like attempting to simulate a human cell. Financial institutions use them to attempt to predict the economy, the stock market, and the like. Automobile manufacturors use them to simulate crash tests. Aeronautic firms use them to simulate new vehicles.
In the past, there has been talk about companies that exist solely to supply compute power. Such a company would have a warehouse full of computers and control them through schedulers (batch, etc.) and sell time on the machines to anyone who wanted it. So far, I don't think anyone has been successful with the idea yet.
I dunno... many of the HPC machines I've seen use batch schedulers and do, in fact, run at near 100% CPU utilization for weeks on end. When you have 1000s of scientists from all over the world all queuing up jobs to be run and each job takes a while, the machine tends to stay busy. We even had jobs that took multiple days to run even when running on 64+ CPUs (all of them busy at 100% for as long).
Many of these machines at the national labs (Sandia, ORNL, WES, etc.) are actually used by scientists all over the USA, if not the world, so it isn't like the machine only runs the jobs that the folks at the site need run.
I've found just the opposite to be true. I've almost invaribly seen Linux run faster and more reliably than Windows on the same hardware.
I have *invariably* (no "almost" qualification) seen Windows run faster than Linux on the same exact hardware, and I've seen Linux/Windows run on the exact same hardware on 100s of machines.
Mostly, this is due to how crappy gcc was in the past as producing fast code. For example, We had a PPro 200 box (yea, this was a while back) that dual booted Windows and Linux. We also had an Intergraph TD dual Pentium 133. Both had like 512M memory (a huge amount back then). Some guys had some code they had written on Linux and asked me to quick port it to Windows and benchmark it for them for a paper so I did. After I ported it and sent them the results (never having seen the Linux results), they sent me email back saying I had messed up something, like maybe the routines to get the time stamps for comparison for execution. I checked it out a bunch and could find no problem with them and they produced accurate results. The problem was that the Windows code was performing 2X or more faster than their gcc compiled code. So, they brought their machine over (was exactly the same hardware as ours) and installed a dual boot Windows on it and we ran the tests on the two OSs on *their* hardware for both Windows and Linux. Sure enough, 2X or better on FPU intensive code. To make matters worse, our Pentium 133s running Windows outperformed their PPro 200 on some of their benchmarks. However, since then, gcc has gotten a lot better. It still isn't as good most of the time, but it isn't nearly as bad as it was.
Reliably on the same hardware is another story... But... I've seen some very reliable Windows hardware in the past as well.
All that being said, I've been working for the past year as a 100% Linux developer and my background before that Windows stuff was on Solaris and Irix 100%.
Only for immediate data. Most data will reside in memory locations and/or registers. The op code (and operand) size for these operations shouldn't be any larger than the ones for 32-bit values.
// should be the same size regardless of the size of the data manipulated // same
// should be opcodes smart enough to load this value (1) using a small number of bits // same
Examples:
add r1,r2,r3
load r1, (r7)
Immeditates will possibly be effected, depending on whether the opcodes exist to use the smaller immediates.
Examples:
load r1, #1
add r1, #256
This isn't anything new... a good compiler can/will rearrange loops and such so that it initiates fetches for the n+1 iteration during the nth iteration (this is regardless of platform). Other CPUs in the past had special instructions that were specifically designed to initiate memory reads in order to load the caches (L1 and/or L2) without actually doing anything with the data being loaded (not actually put it in any register, for example) simply so it will be in cache when it is needed.
Transactional buses are good for other things, though (more so than preloading data, as mentioned here).
I don't know of any FPU made in the last 20 years that have to break 64-bit FPU up into 32-bit operations. They make take longer (FPU optimized for 32-bit operations so 64-bit take a few cycles longer) but they are still handled natively.
The previous poster was talking about 32-bit and 64-bit integer values.
VS.NET runs great for me on WinXP. What kind of system do you have? If you have less than 512M memory, upgrade.
Also, don't do like one site I was at did... they had/have a bunch of P4 Celerons (1.5GHz Willies) running on PC133 memory... that's just horrible to begin with before actually trying to do any work.
I'm not sure why everyone insists on confusing the matter by using base 10 prefixes when there are base 2 prefixes available that are unambiguous.
Because we were using those prefixes in the computer world long before most of you were born and think it's quite rude for you folks to come along and try to change our vocabulary for us. Contrary to what you folks seem to think, WE know exactly what we are talking about, it's you folks who seem to have a problem understanding it and make up these rediculous sounding prefixes to "fix" a problem that doesn't exist other than through your own issues.