No, waste heat doesn't have a noticeable impact on the (global) climate. Here's a much simplified explanation why.
The earth is (roughly) in equilibrium with space. The earth continuously receives a huge amount of energy from the sun, but all that energy is also radiated away into space (obviously, otherwise we'd all have boiled away eons ago), mostly in the infrared spectrum.
So when you run your lawnmower, yes it does create heat, but it also ever so slightly moves the earth away from the equilibrium point and hence the earth starts to radiate heat a little faster until once again the equilibrium is reached.
Now, the deal with greenhouse gases is not that they are hot exhaust gases that heat up the earth. As described above, the extra heat content is just radiated away. The point is that the greenhouse gases alter the equilibrium point by reflecting infrared radiation back to the earth. In a way, they form a sort of insulating heat blanket around the earth.
And yes, water vapor has been included in climate models for a long time, and actually it's effect is pretty big. The reason nobody talks about it is not a conspiracy, but rather that the amount of water vapor in the atmosphere is mostly dependent on the temperature, which in turn is influenced by other greenhouse gases such as CO2. I.e. water vapor amplifies the effect of CO2, but it's not politically interesting since we can't affect the rate of water evaporation directly on a large scale, but we can reduce CO2 emissions.
Re:Isn't it high time for a 80x86 cleanup?
on
Larrabee ISA Revealed
·
· Score: 5, Informative
There are lots of instructions and other craft inside 80x86 processors that occupy silicon that is never used. A clean break from 80x86 is needed. Legacy 80x86 code can run perfectly in emulation (and need not be slow, using JIT techniques).
All the legacy junk takes up a pretty small fraction of the area. IIRC on a modern x86 CPU like Core2 or AMD Opteron, it's somewhere around 5%. Most of the core is functional units, register files, and OoO logic. For a simple in-order core like Larrabee the x86 penalty might be somewhat bigger, but OTOH Larrabee has a monster vector unit taking up space as well.
What I like most about Larrabee is the scatter-gather operations. One major problem in vectorized architectures is how to load the vectors with data coming from multiple sources. the Larrabee ISA solves this neatly by allowing vectors to be loaded from different sources in hardware and in parallel, thus making loading/storing vectors a very fast operation.
Yes, I agree. Scatter/gather is one of the main reason why vector supercomputers do very well on some applications. E.g. scatter/gather allows sparse matrix operations to be vectorized, and allows the CPU to keep a massive number of memory operations in flight at the same time, whereas sparse matrix ops tend to spend their time waiting on memory latency when you have just the usual scalar memory ops.
The programming languages that will benefit from Larrabee though will not be C/C++. It will be Fortran and the purely functional programming languages. Unless C/C++ has some extensions to deal with the pointer aliasing issue, that is.
There is the "restrict" keyword in C99 precisely for this reason. It's not in C++ but most compilers support it in one way or another (__restrict, #pragma noalias or whatever). That being said, I'd imagine something like OpenCL would be a more suitable language for programming Larrabee than either C, C++ or Fortran. Functional lnaguages are promising for this as you say, of course, but it remains to be seen if they manage to break out of their academic ivory towers this time around.
Re:If Intel are smart they will mix Core and Larab
on
Larrabee ISA Revealed
·
· Score: 1
Yeah, most x86_64 ABI's use SSE for scalar floating point, so it's too late to remove it. But hey, at least SSE is an improvement over x87.
Isn't this exactly what Gallium3d + LLVM GLSL compiler is giving you? Heck, even with the simple shader ISA's you probably want an optimizing compiler anyway in order to get good GLSL performance, no?
Wouldn't this actually be a good thing; instead of spending all the time developing new drivers for each generation of hw (changing every 6 months, poorly if at all documented), you could just keep on developing the architecture and improve the x86 backend.
Metadata is things like directory entries, and where on disk your file exists, whereas the data is just the contents of the file itself. Without metadata, you wouldn't have a file system, but rather a huge blob of bits with no way of knowing which bits belong to which file. So yeah, your comment makes no sense.
Your benchmark numbers are obviously incorrect. This is because your compiler can see through the simple array test and sees that it does nothing, hence optimizes the entire thing away. A common problem in benchmarking.
As for the code itself, you're comparing apples to oranges. You start with an std::vector of size 0, and grow it over time as you push_back() stuff into it. The equivalent simple array implementation would be to start with a 1 element array, and realloc() to twice the size when needed. So obviously the vector implementation has to do a lot of realloc() + copy operations. You can get around this with the vector.reserve() function, which allows you to allocate enough memory up front. Or alternatively, there is the resize() function allowing you to, well, resize the vector to the right size and write to the elements directly with inta[i] etc.
In this case, neither of these will get quite the same performance as the C array; the reserve() method suffers from having to update the size as you push_back(), and resize() suffers due to STL specifying that container should start zero initialized. But the difference is pretty small; on my laptop the vector test takes a factor of 1.4 longer than the simple array. In a real application, it's likely the difference will be negligible.
OTOH, many businesses won't contribute to BSD licensed projects, since they don't want to spend time developing code that their competitors can then take and incorporate into their proprietary products.
Is the net gain more than the net loss?
Since neither you nor I have a statistically valid sample of the boardroom discussions that led to a companies deciding to release or not to release code under the XXX license, we can scream about this until we are blue in the face and be none the wiser.
That being said, I don't think that is a particularly fruitful approach, as it seems to imply that there is the one true license, if only everybody else would see the light. However, different companies and different individuals have different values. How nice then that Bruce Perens has gone through the trouble of endorsing the best licenses that cover the major bases. While this won't of course make all those zillion other licenses go away, I hope they will at least become increasingly marginalized.
Perhaps, but large trucks make up a large percentage of the traffic on our interstate highway system, and the increases in gas tax will hit them the hardest.
Since the wear and tear on the road due to a vehicle IIRC scales as the axle weight^4, it's only fair that truckers should pay more. It might even cause some transportation to move towards less environmentally damaging forms such as rail or ships.
Suggesting that you could replace a MS-SQL server with SQLite basically forces anybody in the know to ignore every other point you make.
Why? At work we have a MSSQL DB, and TBH, it could easily be replaced with SQLite with no noticeable loss in performance or functionality that we actually use.
That does of course not mean that every MSSQL deployment could be replaced with SQLite, far from it. But I also believe we're far from the only case were we use a DB engine that is vastly overqualified for our actual needs. But hey, our PHB loves it, so we'll keep using it.
Yeah, but an MPI job can't recover from a failed node. Except for checkpointing, of course. So if you launch a job on all those 1.6e6 processors, they all better on average stay up at least long enough that you make some progress and write a checkpoint before one node crashes.
The parent said that the computer will be used for "mapping every reaction" between molecules. Presumably, since reactions tend to require quantum mechanical descriptions, I guessed the parent meant that the new computer would allow doing such calculations for all reactions in a rather large area.
I don't get what you are saying when you ask a question, relate it to the parent's post, and then say it is irrelavent.
Just a gedanken experiment to amuse myself, while noting that it actually has nothing do with simulating nuclear weapons. Don't get too worked up about it.
And, do you realize how much processing power 20 petaflops is?
Yes, it's about 2 orders of magnitude more than the supercomputer I'm using at the moment. A lot for sure, but still limited to very small system sizes for quantum mechanical calculations. At the moment, even the best methods in practice scale as N^3 or so. With my current 100 TFlops I might do a DFT calculation with O(10000) atoms or so. Two orders of magnitude more CPU power with N^3 scaling gives me roughly a factor of 5 more atoms. 50000 atoms fit into a box of roughly 10x10x10 nm (depending on the material etc., of course). Still a way to go until I'm able to do "square miles"..
If you want to go into classical molecular dynamics, then you're obviously in much better shape. With the current supercomputer that's maybe around 1E9 atoms, and since MD scales linearly, with two orders of magnitude more flops it means around 1E11 atoms. Now these fit into a box on the order of 1 um**3. Again, still quite a way to go to square miles..
In conclusion, atoms are really really tiny, and in 3 dimensions you can pack a lot of them into a very tiny volume.
Also, they so far have not needed to calculate what a nuclear bomb does for each atom (obviously, since it has been nigh impossible), and they probably won't ever need to really. You can study waves and energy effects in great detail, and simulate them accurately, without needing to know where each and every atom goes. This will simply let them be more precise and accurate, as well as speedy.
Yes, that was sort of implied in my previous post. The US nuke labs have been at the forefront in research on numerical methods in topics such as shock propagation (PPM and methods like that) and really really large FEM simulations. Obviously, the actual nuclear reactions are taken into account probabilistically rather than the full quantum mechanical treatment (as my above monologue shows, such a treatment for the primary is far beyond any computer in sight). AFAIK they use Monte Carlo neutron diffusion rather than the classical multigroup diffusion methods that AFAIK are still largely used for civilian reactor design. That being said, I'm sure they are doing a lot of atomic and quantum level simulations as well for small model systems designed to e.g. extract parameters for continuum simulations and such.
Uh, do you know how many molecules there are in "square miles"?
Do you know how many atoms you can calculate reactions between using both state of the art supercomputers and quantum chemistry tools?
Do you know the scaling behavior of quantum chemistry methods?
I mean, even with this new supercomputer, your estimate is off by ridiculously many orders of magnitude.
And that being said, nuke simulation has little to do with quantum chemistry anyways.
You're playing a straw man game by assuming an UAV is either the flimsy reconnaissance drones of today or some UAV version of the F-22.
For example, there are plenty of
combat UCAV prototypes being designed. Most of the more advanced ones are stealth. Now at the moment all of these design seem focused on bomb truck duty, but I think it's rather naive to assume that, given the rate at which the technology is developing, an air-to-air focused UCAV design couldn't beat the F-22 in, say, a decade or two.
Who knows what will happen, maybe we'll have something involving supraconductors, magnetohydrodynamic propulsion, some stuff we haven't discovered, and so on.
Or maybe we'll run out of cheap oil, suburbia dies and except for the farmers the rest of us will be forced to adopt a low energy lifestyle, living in dense cities and traveling with electrified mass transit (think cramming like sardines aka the Tokyo subway).
As for automated cars, Brad Templeton (of EFF fame) has a site puffing them.
Unless you're playing tricks like storing other data into the upper bits of pointers, this shouldn't matter; from the application perspective addresses are 64-bit. With current hardware a bunch of bits is always zero, but allowing applications to use more memory should come transparently with newer hardware generations, with no recompilation necessary.
El Naschie's writing looks like nonsense even to non-specialists (though I guess you still need a degree in mathematics or physics). There's no way it could fool even beginners in the areas his work covers. That makes it all the more astonishing that he survived with Elsevier for so long. Apathy I guess.
Greed is my guess. There's a comment on the blog saying that some researchers wrote a complaint about CSF to Elsevier about a year ago, Elsevier answered "thank you , we're going to look into it". But until Baez caused a PUBLIC outcry over this, they did absolutely jack shit.
Unfortunately Using Samba is almost 10 years old by now, and some of the tuning advice might not be applicable any more. In particular, newer versions of the linux kernel (2.6.17+) have full tcp autotuning. But explicitly specifying buffer sizes (socket options SO_RCVBUF and SO_SNDBUF) will disable this autotuning. So using some value that was good 10 years ago (8192) might be pretty far from optimal these days.
If the genocide in Sudan succeeds in killing all blacks there, the AFP will personally go down and congratulate the sudanese government on a jihad well done
Just exactly what "color" do you think the Sudanese government are?
If the genocide succeeds in killing all the blacks, the remaining people (including the government, assuming the government consists of people, which I suppose might be a stretch..) must hence be non-black.
Slashdot Mirror
No, waste heat doesn't have a noticeable impact on the (global) climate. Here's a much simplified explanation why.
The earth is (roughly) in equilibrium with space. The earth continuously receives a huge amount of energy from the sun, but all that energy is also radiated away into space (obviously, otherwise we'd all have boiled away eons ago), mostly in the infrared spectrum.
So when you run your lawnmower, yes it does create heat, but it also ever so slightly moves the earth away from the equilibrium point and hence the earth starts to radiate heat a little faster until once again the equilibrium is reached.
Now, the deal with greenhouse gases is not that they are hot exhaust gases that heat up the earth. As described above, the extra heat content is just radiated away. The point is that the greenhouse gases alter the equilibrium point by reflecting infrared radiation back to the earth. In a way, they form a sort of insulating heat blanket around the earth.
And yes, water vapor has been included in climate models for a long time, and actually it's effect is pretty big. The reason nobody talks about it is not a conspiracy, but rather that the amount of water vapor in the atmosphere is mostly dependent on the temperature, which in turn is influenced by other greenhouse gases such as CO2. I.e. water vapor amplifies the effect of CO2, but it's not politically interesting since we can't affect the rate of water evaporation directly on a large scale, but we can reduce CO2 emissions.
There are lots of instructions and other craft inside 80x86 processors that occupy silicon that is never used. A clean break from 80x86 is needed. Legacy 80x86 code can run perfectly in emulation (and need not be slow, using JIT techniques).
All the legacy junk takes up a pretty small fraction of the area. IIRC on a modern x86 CPU like Core2 or AMD Opteron, it's somewhere around 5%. Most of the core is functional units, register files, and OoO logic. For a simple in-order core like Larrabee the x86 penalty might be somewhat bigger, but OTOH Larrabee has a monster vector unit taking up space as well.
What I like most about Larrabee is the scatter-gather operations. One major problem in vectorized architectures is how to load the vectors with data coming from multiple sources. the Larrabee ISA solves this neatly by allowing vectors to be loaded from different sources in hardware and in parallel, thus making loading/storing vectors a very fast operation.
Yes, I agree. Scatter/gather is one of the main reason why vector supercomputers do very well on some applications. E.g. scatter/gather allows sparse matrix operations to be vectorized, and allows the CPU to keep a massive number of memory operations in flight at the same time, whereas sparse matrix ops tend to spend their time waiting on memory latency when you have just the usual scalar memory ops.
The programming languages that will benefit from Larrabee though will not be C/C++. It will be Fortran and the purely functional programming languages. Unless C/C++ has some extensions to deal with the pointer aliasing issue, that is.
There is the "restrict" keyword in C99 precisely for this reason. It's not in C++ but most compilers support it in one way or another (__restrict, #pragma noalias or whatever). That being said, I'd imagine something like OpenCL would be a more suitable language for programming Larrabee than either C, C++ or Fortran. Functional lnaguages are promising for this as you say, of course, but it remains to be seen if they manage to break out of their academic ivory towers this time around.
Yeah, most x86_64 ABI's use SSE for scalar floating point, so it's too late to remove it. But hey, at least SSE is an improvement over x87.
Isn't this exactly what Gallium3d + LLVM GLSL compiler is giving you? Heck, even with the simple shader ISA's you probably want an optimizing compiler anyway in order to get good GLSL performance, no?
Wouldn't this actually be a good thing; instead of spending all the time developing new drivers for each generation of hw (changing every 6 months, poorly if at all documented), you could just keep on developing the architecture and improve the x86 backend.
Metadata is things like directory entries, and where on disk your file exists, whereas the data is just the contents of the file itself. Without metadata, you wouldn't have a file system, but rather a huge blob of bits with no way of knowing which bits belong to which file. So yeah, your comment makes no sense.
Um, they are using bzr. The official MySQL tree is on launchpad. IIRC Drizzle and Maria are also hosted there.
You didn't provide results from a fixed benchmark to compare with, so what conclusion am I supposed to draw from you results?
Anyway, in my case, if I run the second loop 100 times the difference between the simple array and vector tests vanish, as expected.
Your benchmark numbers are obviously incorrect. This is because your compiler can see through the simple array test and sees that it does nothing, hence optimizes the entire thing away. A common problem in benchmarking.
As for the code itself, you're comparing apples to oranges. You start with an std::vector of size 0, and grow it over time as you push_back() stuff into it. The equivalent simple array implementation would be to start with a 1 element array, and realloc() to twice the size when needed. So obviously the vector implementation has to do a lot of realloc() + copy operations. You can get around this with the vector.reserve() function, which allows you to allocate enough memory up front. Or alternatively, there is the resize() function allowing you to, well, resize the vector to the right size and write to the elements directly with inta[i] etc.
In this case, neither of these will get quite the same performance as the C array; the reserve() method suffers from having to update the size as you push_back(), and resize() suffers due to STL specifying that container should start zero initialized. But the difference is pretty small; on my laptop the vector test takes a factor of 1.4 longer than the simple array. In a real application, it's likely the difference will be negligible.
In case you didn't know, it's part of the classic "Who's on first" by Abbott and Costello
The kernel uses lazy context switching for floating point registers. A side-effect of this is that the kernel itself cannot use those registers.
OTOH, many businesses won't contribute to BSD licensed projects, since they don't want to spend time developing code that their competitors can then take and incorporate into their proprietary products.
Is the net gain more than the net loss?
Since neither you nor I have a statistically valid sample of the boardroom discussions that led to a companies deciding to release or not to release code under the XXX license, we can scream about this until we are blue in the face and be none the wiser.
That being said, I don't think that is a particularly fruitful approach, as it seems to imply that there is the one true license, if only everybody else would see the light. However, different companies and different individuals have different values. How nice then that Bruce Perens has gone through the trouble of endorsing the best licenses that cover the major bases. While this won't of course make all those zillion other licenses go away, I hope they will at least become increasingly marginalized.
Since the wear and tear on the road due to a vehicle IIRC scales as the axle weight^4, it's only fair that truckers should pay more. It might even cause some transportation to move towards less environmentally damaging forms such as rail or ships.
Why? At work we have a MSSQL DB, and TBH, it could easily be replaced with SQLite with no noticeable loss in performance or functionality that we actually use.
That does of course not mean that every MSSQL deployment could be replaced with SQLite, far from it. But I also believe we're far from the only case were we use a DB engine that is vastly overqualified for our actual needs. But hey, our PHB loves it, so we'll keep using it.
=> A big happy incestuous family!
Yeah, but an MPI job can't recover from a failed node. Except for checkpointing, of course. So if you launch a job on all those 1.6e6 processors, they all better on average stay up at least long enough that you make some progress and write a checkpoint before one node crashes.
The parent said that the computer will be used for "mapping every reaction" between molecules. Presumably, since reactions tend to require quantum mechanical descriptions, I guessed the parent meant that the new computer would allow doing such calculations for all reactions in a rather large area.
I don't get what you are saying when you ask a question, relate it to the parent's post, and then say it is irrelavent.
Just a gedanken experiment to amuse myself, while noting that it actually has nothing do with simulating nuclear weapons. Don't get too worked up about it.
And, do you realize how much processing power 20 petaflops is?
Yes, it's about 2 orders of magnitude more than the supercomputer I'm using at the moment. A lot for sure, but still limited to very small system sizes for quantum mechanical calculations. At the moment, even the best methods in practice scale as N^3 or so. With my current 100 TFlops I might do a DFT calculation with O(10000) atoms or so. Two orders of magnitude more CPU power with N^3 scaling gives me roughly a factor of 5 more atoms. 50000 atoms fit into a box of roughly 10x10x10 nm (depending on the material etc., of course). Still a way to go until I'm able to do "square miles"..
If you want to go into classical molecular dynamics, then you're obviously in much better shape. With the current supercomputer that's maybe around 1E9 atoms, and since MD scales linearly, with two orders of magnitude more flops it means around 1E11 atoms. Now these fit into a box on the order of 1 um**3. Again, still quite a way to go to square miles..
In conclusion, atoms are really really tiny, and in 3 dimensions you can pack a lot of them into a very tiny volume.
Also, they so far have not needed to calculate what a nuclear bomb does for each atom (obviously, since it has been nigh impossible), and they probably won't ever need to really. You can study waves and energy effects in great detail, and simulate them accurately, without needing to know where each and every atom goes. This will simply let them be more precise and accurate, as well as speedy.
Yes, that was sort of implied in my previous post. The US nuke labs have been at the forefront in research on numerical methods in topics such as shock propagation (PPM and methods like that) and really really large FEM simulations. Obviously, the actual nuclear reactions are taken into account probabilistically rather than the full quantum mechanical treatment (as my above monologue shows, such a treatment for the primary is far beyond any computer in sight). AFAIK they use Monte Carlo neutron diffusion rather than the classical multigroup diffusion methods that AFAIK are still largely used for civilian reactor design. That being said, I'm sure they are doing a lot of atomic and quantum level simulations as well for small model systems designed to e.g. extract parameters for continuum simulations and such.
Uh, do you know how many molecules there are in "square miles"? Do you know how many atoms you can calculate reactions between using both state of the art supercomputers and quantum chemistry tools? Do you know the scaling behavior of quantum chemistry methods? I mean, even with this new supercomputer, your estimate is off by ridiculously many orders of magnitude. And that being said, nuke simulation has little to do with quantum chemistry anyways.
For example, there are plenty of combat UCAV prototypes being designed. Most of the more advanced ones are stealth. Now at the moment all of these design seem focused on bomb truck duty, but I think it's rather naive to assume that, given the rate at which the technology is developing, an air-to-air focused UCAV design couldn't beat the F-22 in, say, a decade or two.
The probably use normal mogas all the time. The engine is designed to work with it, so there's no need to use the (very expensive) 100LL.
Who knows what will happen, maybe we'll have something involving supraconductors, magnetohydrodynamic propulsion, some stuff we haven't discovered, and so on.
Or maybe we'll run out of cheap oil, suburbia dies and except for the farmers the rest of us will be forced to adopt a low energy lifestyle, living in dense cities and traveling with electrified mass transit (think cramming like sardines aka the Tokyo subway).
As for automated cars, Brad Templeton (of EFF fame) has a site puffing them.
I don't remember ever seeing an Alpha running anything other than VMS in the real world.
We had boatloads of Alphas over here, and they were all running Digital Unix. Nowadays it's all x86(-64)-Linux or Windows, though.
Unless you're playing tricks like storing other data into the upper bits of pointers, this shouldn't matter; from the application perspective addresses are 64-bit. With current hardware a bunch of bits is always zero, but allowing applications to use more memory should come transparently with newer hardware generations, with no recompilation necessary.
El Naschie's writing looks like nonsense even to non-specialists (though I guess you still need a degree in mathematics or physics). There's no way it could fool even beginners in the areas his work covers. That makes it all the more astonishing that he survived with Elsevier for so long. Apathy I guess.
Greed is my guess. There's a comment on the blog saying that some researchers wrote a complaint about CSF to Elsevier about a year ago, Elsevier answered "thank you , we're going to look into it". But until Baez caused a PUBLIC outcry over this, they did absolutely jack shit.
Unfortunately Using Samba is almost 10 years old by now, and some of the tuning advice might not be applicable any more. In particular, newer versions of the linux kernel (2.6.17+) have full tcp autotuning. But explicitly specifying buffer sizes (socket options SO_RCVBUF and SO_SNDBUF) will disable this autotuning. So using some value that was good 10 years ago (8192) might be pretty far from optimal these days.
Just exactly what "color" do you think the Sudanese government are?
If the genocide succeeds in killing all the blacks, the remaining people (including the government, assuming the government consists of people, which I suppose might be a stretch..) must hence be non-black.