If you really want to use HDF5 with with Fortran77, just make a few wrappers for the C APIs that convert pass-by-reference to pass-by-value where appropriate. You don't have to do it for the whole HDF5 API, just the parts of it that you need.
Just so you know, the vast majority of scientific software does not use HDF5. We'd love it if they did, but I can guarantee you that nothing like 75% (i.e. a vast majority) of scientific codes use HDF (4 or 5). In fact, I'd wager that it's 20% or less (whether measured in numbers or cycles).
You've left out a party. It hurts the sites that are filtered!
When the government makes a decision as to which sites to put on the list, that is a non-content-neutral, prior restraint on their speech (a well decided, forbidden form of government regulation). The mere fact that the government publishes a list of 'bad' sites is an unconstitutional step that values some speech above others.
If the law is redundant, and clearly unconstitutional, why bother?
This has nothing to do with opt-in versus opt-out. When the government makes content-oriented decisions, that infringes the rights of content producers, period. The 900 number blocking program is not content oriented. It's charge-avoidence oriented. That's what makes it constitutionally permissable and Utah's porn list not.
The reason 900 and 976 numbers are blockable at the phone company by request is not that they are phone sex lines, but that they charge directly to your phone when you call it. For the same reason you can have the phone company make it impossible to make other types of toll calls from your phone (i.e. long distance, etc.). It has nothing to do with sex.
Why not just use something like cmod to handle all your PATH (MANPATH, LD_LIBRARY_PATH, et. al.) related problems? I've been doing this on my home machines for years and _never_ had a problem. Any packages I build by hand go in/opt/packagename/version_number, and a module file gets created. The extra step saves headaches down the road, and allows me to have multiple versions of the same package installed at the same time. Nothing could be simpler.
P.S. Don't let the fact that cmod hasn't been updated in 6 or so years throw you. It's like TeX....bugfree.
Actually, viscoelastic is a combination of viscous and elastic (obviously) which means that the stress in a material is a combination of the rate and amount of strain.
Just like the minutes used for voice, both sending and receiving SMS users are charged. However, like the other guy said, if the SMS originates through an e-mail gateway, then only the recipient pays for the message.
The cell phone companies here in the US get you coming and going, but they take only half as much in each direction. So, in the end, it balances out....sort of.
Not to be rude, but perhaps you're approaching the problem wrong. Anything, _anything, ANYTHING, that can be parallelized for a vector machine can be redesigned for a cluster and achieve a significant fraction of the former's performance. Your claim that the X1 is 3 orders of magnitude faster than a cluster demands stronger evidence and a serious analysis of the algorithm that you're using to solve your problem.
Here's the thing: The slowest you can go in space occurs at the _highest_ point in your orbit. You can't simultaneously be at the highest point in your orbit and significantly decelerating without serious retrorocket fire. Also, skipping off the atmosphere, at best, corresponds to making your orbit more elliptical (and less circular) which means that you are in the atmosphere at the lowest point in your orbit. Which means that you are in the fastest part of your orbit inside the atmosphere (bad). In fact, you may be going faster than in your previously circular orbit even though you've reduced your overall energy (potential + kenetic).
The thermally optimal way to get out of orbit is to retro burn to an instant dead stop and then retro burn against gravity at a rate that doesn't heat you up:) Of course this requires more fuel than you can get to space!
No, my results were better than his inspite of the limitations listed in my first post! My point was that it's not gcc that's sucking but its implementation under Cygwin. Something needs adjusting in his analysis.
I just ran his benchmark with gcc 3.3 under a RH9 linux box with my hand built 2.4.23 and got the following gcc results:
8.8 19.0 8.66 4.35 0.7 40.81
compared to his results of
9.8 28.8 9.5 14.9 10.0 73.0
The columns are the same as his; all numbers are times in seconds. Same compiler flags as his gcc test (except for the -fno-cygwin which isn't aplicable). My system is a 1.4GHz Pentium M (compared to the 2.0GHz Pentium M used in his test). No particular precautions against background processes were taken (in fact I was browsing the osnews site while it was running on another desktop).
Things to note:
My long math results is nearly identical to his Visual C++ result (within a second).
His VC++ doulbe results are still better than mine.
My trig results are comparable to his best (taking the "double" result into account).
Linux blows Windows out of the water in the I/O world (?? maybe he doesn't have DMA turned on on his laptop HDD ??).
I was just thinking that memory bandwidth performance is pretty poor in the x86 SMP world, so if rendering is memory bandwidth limited that might be a problem. Memory bandwidth is less of an issue on the O2k/O3k style machines since there tends to be more of it.:) OTHO, if Maya-style rendering is compute-bound, then I figure it ought to scale OK.
Why would you expect a piece of film to reduce its resolution (in DPI) as it gets bigger? 8x10 b/w film is the same stuff as the 35mm, AFAIK, only bigger. I can't imagine that it's any different in the color world.
Not quite, but close. Ultra320 means, of course, that the maximum transfer rate for single channel operation is 320 MB/sec. This article over at Tom's Hardware gets about 250 MB/s. Not bad for a sinle 10k drive. The future of Ultra320 is out there.
My previous comment was a little tounge in cheek. I know it's not 350, but it's a single drive not a full on ATA RAID implementation.
The real upshot of this discussion is that SCSI rocks and IDE sucks, of course!
... Dead AND Not-Dead...
If you really want to use HDF5 with with Fortran77, just make a few wrappers for the C APIs that convert pass-by-reference to pass-by-value where appropriate. You don't have to do it for the whole HDF5 API, just the parts of it that you need.
Just so you know, the vast majority of scientific software does not use HDF5. We'd love it if they did, but I can guarantee you that nothing like 75% (i.e. a vast majority) of scientific codes use HDF (4 or 5). In fact, I'd wager that it's 20% or less (whether measured in numbers or cycles).
It only works when it's sunny out.
Examiners are on a quota system.
That's for www.slashdot.org, slashdot.org is 35.
Market capitalization != debt.
When the government makes a decision as to which sites to put on the list, that is a non-content-neutral, prior restraint on their speech (a well decided, forbidden form of government regulation). The mere fact that the government publishes a list of 'bad' sites is an unconstitutional step that values some speech above others.
If the law is redundant, and clearly unconstitutional, why bother?
This has nothing to do with opt-in versus opt-out. When the government makes content-oriented decisions, that infringes the rights of content producers, period. The 900 number blocking program is not content oriented. It's charge-avoidence oriented. That's what makes it constitutionally permissable and Utah's porn list not.
The 900 number blocking is content-neutral. The Utah porn blocking is not. That's what matters as far as the constitutionality goes.
The reason 900 and 976 numbers are blockable at the phone company by request is not that they are phone sex lines, but that they charge directly to your phone when you call it. For the same reason you can have the phone company make it impossible to make other types of toll calls from your phone (i.e. long distance, etc.). It has nothing to do with sex.
How about 'alt-d' rather than 'enter'?
Why not just use something like cmod to handle all your PATH (MANPATH, LD_LIBRARY_PATH, et. al.) related problems? I've been doing this on my home machines for years and _never_ had a problem. Any packages I build by hand go in /opt/packagename/version_number, and a module file gets created. The extra step saves headaches down the road, and allows me to have multiple versions of the same package installed at the same time. Nothing could be simpler.
P.S. Don't let the fact that cmod hasn't been updated in 6 or so years throw you. It's like TeX....bugfree.
Actually, viscoelastic is a combination of viscous and elastic (obviously) which means that the stress in a material is a combination of the rate and amount of strain.
The cell phone companies here in the US get you coming and going, but they take only half as much in each direction. So, in the end, it balances out....sort of.
Not to be rude, but perhaps you're approaching the problem wrong. Anything, _anything, ANYTHING, that can be parallelized for a vector machine can be redesigned for a cluster and achieve a significant fraction of the former's performance. Your claim that the X1 is 3 orders of magnitude faster than a cluster demands stronger evidence and a serious analysis of the algorithm that you're using to solve your problem.
The thermally optimal way to get out of orbit is to retro burn to an instant dead stop and then retro burn against gravity at a rate that doesn't heat you up :) Of course this requires more fuel than you can get to space!
No, my results were better than his inspite of the limitations listed in my first post! My point was that it's not gcc that's sucking but its implementation under Cygwin. Something needs adjusting in his analysis.
8.8 19.0 8.66 4.35 0.7 40.81
compared to his results of
9.8 28.8 9.5 14.9 10.0 73.0
The columns are the same as his; all numbers are times in seconds. Same compiler flags as his gcc test (except for the -fno-cygwin which isn't aplicable). My system is a 1.4GHz Pentium M (compared to the 2.0GHz Pentium M used in his test). No particular precautions against background processes were taken (in fact I was browsing the osnews site while it was running on another desktop).
Things to note:
I was just thinking that memory bandwidth performance is pretty poor in the x86 SMP world, so if rendering is memory bandwidth limited that might be a problem. Memory bandwidth is less of an issue on the O2k/O3k style machines since there tends to be more of it. :) OTHO, if Maya-style rendering is compute-bound, then I figure it ought to scale OK.
Just out of curiosity: does Maya scale?
Why would you expect a piece of film to reduce its resolution (in DPI) as it gets bigger? 8x10 b/w film is the same stuff as the 35mm, AFAIK, only bigger. I can't imagine that it's any different in the color world.
truns uot I cna't tpye!
My previous comment was a little tounge in cheek. I know it's not 350, but it's a single drive not a full on ATA RAID implementation.
The real upshot of this discussion is that SCSI rocks and IDE sucks, of course!
Considering that 1 Ultra320 drive does that, I think SCSI has you mostly beat.