Actually, in quantum mechanics, we can see the universes split and join back together again in some cases; it very significantly changes the probabilities that certain events occur.
What happens to any universes that didn't rejoin with ours we can't tell for sure. However, a reasonable assumption seems to be that they still exist, and we have no reason to think that they don't. Most professional physicists believe in the many histories theory of quantum physics, which implies multiple universes.
Unfortunately, most profilers won't tell you that a certain code path only consumes a lot of time when variables a,b,x,y and z are set to 6.3, 5.7, 4.118, 2.05 and "albatross".
Yeah they do. If it's a lot of time. If it's just more than it should have been in that scenario, then no, practically no profiler gives you any idea; it just gives you the average time spent in that routine, not the worst case AFAIK.
Suppose you have a tight loop that creates a few objects and then disposes of them. Further suppose that loop spikes the CPU, as would be the case for something under constant load or with a lot of data to process. Then you will be creating objects faster than the GC can get rid of them, because the GC is a lower priority than your main thread, which is doing the important stuff. GC is, by its nature, a lower priority task.
All I can say is that if the low priority of the GC makes your OS swap in that situation, then I would be very disappointed in that particular JVM, swapping is practically certain to slow the system down in the long run. It's a very common scenario to be continuously generating garbage, and the correct behaviour is for the garbage generating thread to try to allocate an object, fail, block and give the GC a chance to create some space and then carry on.
For example, I do not see how things would become much more dangerous in Java if you added a delete operator to complement the new operator. The operator would have the semantics that meant "delete, now". If you tried to access a deleted object, it would throw an exception.
It's likely to be difficult/slow to implement; the JVM would have to effectively hunt around for all the references to that object and null them out. That might well require searching every object in memory. And if it wasn't safe, then it becomes a security hole- above all Java was designed with safety in mind.
This isn't a valid solution because sometimes your program might actually need that much memory.
I said you can control the initial size of the memory. Many JVMs will normally not go outside that size unless it has already GCd and it still doesn't have enough memory.
I should be able to tell the GC that I am done with an object right here and now, rather than waiting for the low priority GC thread to take too long to pick it up.
Yes, that would certainly be useful; however, you can usually (depending on the VM) kick the GC off at sensible rates or tune the GC to run more often.
Still, there are alternatives; and I generally still prefer using Java inspite of these kinds of relatively minor shortfalls in the language because it is still a more powerful language than C++ (powerful in the sense of my programs being shorter in Java than C++).
Hey here's a thought. I'm not trying to troll, but could it be that you're rubbish at writing Java? Seriously? I mean Java isn't magic. If you don't have insight into what's happening, it will often run slowly- same thing happens with C/C++, it's just you are probably more familiar with those languages.
I've used Java on embedded applications, on systems that create lots, and lots of objects. And I don't recall ever running out of memory, if there wasn't a bug in the Java program.
But I'm not saying you're lying or wrong, only that a well tuned, well supported, JVM doesn't do this.
the opportunistic garbage collection of C/C++ simply leads to better performance than any language that tries to do the garbage collection for you.
What opportunistic garbage collection of C/C++? You mean delete and free? Get real! Personally, I wouldn't trust the average programmer to even collect garbage correctly more than half the time, and that doesn't cut it. I've had way, way less problems with Java GC than I've ever had with C/C++ in a realtime system. People have spent weeks finding memory leaks; and one time a leak I found was a ghastly C++ compiler bug where the compiler screwed up the automatic destructors on unnamed objects.
If it starts to do this, you can usually change the JVM settings to restrict the initial memory the JVM has. That way it will only grow if it really needs to.
And when your CPU is spiked by an inner processing loop, the garbage collector which probably runs at a lower thread priority will not be given enough CPU to clear out memory fast enough.
For what exactly? The GC is supposed to free up ALL of the garbage (provided you have nulled the pointers). Anything else is a bug in the JVM; there certainly are bugs in just about any piece of software, including JVMs.
I mean, the java code can run just as fast, as long as your JVM is optimizing on the fly based on dynamic code profiling... of course, it won't seem faster because the dynamic profiling and recompiling is expensive, but the original code is running faster!
I believe that Hotspot only profiles the code for a while, and then switches off the profiling. The code runs a bit slowly for a short while as it is optimised and then runs at full speed.
Yeah, but that won't cause you to crash on any JVM I've ever used. What happens is it carries on allocating until it hits the limit and then starts GCing; the limit may well be megabytes- GCing takes a little while and many JVMs are tuned to avoid doing any GC if they don't have to (they benchmark better that way); but you can often adjust the JVM to GC much more often than that.
My advice is don't follow the link, it's trash. Check this out:
People dealing with time series data will use a time class. Anybody using these will definitely hate trading a zero-time stack allocation for a constant-time heap allocation. Put that in a loop and that becomes O (n) vs. zero. Add another loop and you get O (n^2) vs. again, zero.
What? A constant time operation in an 'n' loop is O(n), but then again, the loop is O(n) to start with. Add another loop and you get O(n^2) versus O(n^2). The constant of proportionality has changed, but that's all. If you were using C++, you'd probably call a constructor and possibly destructor anyway; so the difference is not nearly as much as you'd expect; and java heap allocation is only about 3 instructions anyway on a decent VM. This article is total junk.
Remember the DOS days? Was was GWBASIC so slow? Why were QuickBASIC programs so slow?
Why, later, was Surak so slow?
It's because Surak has never written a line of Java in his life and simply trots out the same tired old message that he heard 4 years ago on Slashdot and repeats whenever Java comes up.
Surak is essentially regurgitating, inspite of JITs and JNIs actually writing pretty good machine code these days.
Suraks are slow. That's why people try to avoid hiring them.
It's more than just NIH; if NASA buys Soyuz from the Ruskies, then they've spent American tax dollars on Russian hardware, and the money will create multiple jobs in Russia, rather than jobs in America. Basically, America becomes slightly less prosperous, but the effect is tiny (the proportion of tax dollars that goes to NASA is minute, compared to the overall budget).
Of course the fact that they don't do this, makes NASA a monopoly and gives it completely no incentive to clean up it's act; so in the long run, America in general, and American space in particular, is worse off.
Still, Boeing's SeaLaunch has pretty much done this. It doesn't look like a wild success at the moment, but it will hopefully improve.
One might be tempted to speculate as to where the professor obtained the material, and/or whether he passed it on to someone else in the company. If so, and the person is still in the company and in a position of power, then you would expect these people to be fired from their jobs.
Still, that would be speculation on my part, and I have no other evidence as to whether this is indeed happening at this company. It's not impossible that the people have indeed been slacking at their jobs, although from what I've seen of the evidence they do not seem to have been doing so in any significant way.
Yes, well, as a rule of thumb, european money only goes back to the country that invested it anyway (same thing happens with NASA), so I doubt it would have made that much difference.
The other week I took an IQ test. I got the same IQ as my father. However he got 6 fewer questions out of 60 than me. How come? Well, he's older naturally. It seems that the brain slows by about 10% as you get older, (and interestingly below the age of 21 you're slower too). The IQ test score accounts for that age difference, and we ended up with the same score.
But, 10% isn't that bad.
So, I don't think it's biological. I think it's more to do with stuff like spare time, having a drive to do something, looking at new material rather than being stuck doing the same thing all the time and so on; having children to look after etc. etc.
It's a software problem, not a hardware problem. And people can rewrite their software, and it gets rewritten by people around you all the time (although their are limits!)
The most successful scramjets work great for the 30 seconds or so until they, as designed, melt. And it's not that they wanted them to melt, they pretty much melt whatever you do.
There are lots of problems with scramjets. They've been a research project for decades and it's only in the last few years that one even gave positive thrust in real flight.
The problems with trying to survive at mach 6+ in thick atmosphere should not be underestimated, it is a far, far worse environment than the Shuttle faces when reentering (check out Columbia), and the Shuttle gets it over and done with as soon as possible, giving the heat less time to soak into the vehicle. A scramjet spends a lot longer going fast in thick atmosphere, and the temperature issues this causes on the outer skin is just awesome, never mind inside the scramjet itself.
I don't think that's what killed HOTOL. Quite a bit of it is in the public domain.
The main thing that killed it, was the projected development cost- around $20 billion or more (and I think these are 1980 prices). The engines look like they would be really expensive to design, and they are the heart of the vehicle. Basically, he couldn't find anyone to fund it.
But a single space launch uses a hell of a lot of fuel and creates a lot of pollution - this is not sustainable.
That's not actually true. A rocket produces about the same amount of pollution as burning the same amount of fuel in a car engine. The main pollutant it creates is CO2, and it doesn't, overall, produce any CO2 if you use biomass to make the rocket fuel (since the plants suck up as much CO2 as they grow as the rocket produces).
Yes, rocket propulsion is efficient in a chemical-kinetic energy transfer way, but not efficient if all other costs are taken into account.
Nonsense. It doesn't even use that much fuel. First, 2/3 of the fuel is liquid oxygen, it's cheap and environmentally friendly. That's produced from liquid distillation of air. That leaves about 20 kgs of fuel needed for each kg of payload. A person weighs, say 200 kg, including spacesuit. That means you need 4000kg of fuel. That's about the same amount of fuel as I burnt in my car last year. It's a lot, but not an overwhelming amount, and it's not like I go shopping in my rocket every day, going into space is a rare event.
Use geo-thermal energy to power such a mag-lev launcher thing... I find that preferable.
Yeah, but if you have the geo-thermal, why not use it to make hydrogen, and launch with that in a conventional rocket? That way you can do it for a few billion rather than 100 trillion dollars or whatever a 50km long mag-lev launcher would cost. How much pollution would be made in constructing that anyway?
You only have two thermal reserviors, the iron, and the probe. By allowing the transfer of X watts of heat from the iron to the probe, you can generate N <= X watts of usable energy.
No, you big dope. You don't generate energy by letting heat into the probe! You're right that's dumb, but I never suggested you do that.
You can generate energy by generating a hot reservoir above the external molten iron temperature and then running a heat engine between it and the outside, and then take the energy from that and run the refrigerator.
With that N watts of usable energy, you can transfer Y <= N watts of heat out of the probe. Y <= X. At 100% efficiency, the most heat you can transfer out is the heat you let in to generate the power in the first place. You cannot use heat flowing naturally from A->B to actively transfer a greater amount of heat from B->A. If that were possible, AC units would be self-powering.
To run a powered air conditioner you need a copule of things the heat sink used to generate the power needs to have a greater temperature difference from its associated cold sink than the object to be cooled does relative to its surroundings.
Good posting. However, that last point seems dubious, unless I've missed something stupid, but I don't think so.
If I had a 1 degree temperature difference on my hot sink, but a 50 degree temperature difference on my refrigerated section, I can still run the refrigerator to maintain the 50 degree difference if I allow a lot of heat flow to go between the hot sink and the cold sink, enough to run the refrigerator to maintain 50 degrees. You'll get really rotten efficiency with the generator section, but it works fine.
Yes, I want that, no it doesn't exist. And no, I don't need it to ensure that the inside of a refrigerator is cooler than it's surroundings, whether the refrigerator is surrounded by molten iron or gaseous air; it makes no difference.
Admittedly the practical difficulties of the molten iron case are harder, but the maths is very much the same. If your kitchen refrigerator works, then so does one surrounded by molten iron, if designed correctly.
That kind of comment is more of a what you are doing to remove duplicates, rather than a why. I don't have any problem with that comment, it's an excellent comment. But if you had added a comment to the insertItem function to mention that they needed to be sorted so that the removeDuplicates worked properly, then that's not right, that's what documentation is for.
The refrigerator must also necessarily generate thermal energy during their operation.
Yup. Nothing is 100% efficient. In fact there's a theoretical limit to how efficient it can be which is the Carnot cycle.
So, if we assume the refrigerator starts out at the same temperature as the rest of the probe, its temperature will rise above that of the probe, causing heat to flow from the refrigerator to the probe.
No. The waste heat flows out to the hot iron outside where it is conducted away.
This will cause the refrigerator to have to transfer more heat, which means more heat generation, and since the heat generated will always outpace the heat transfer, the probe melts.
No. The infinite series converges to a finite value, because the fraction of heat pumped is larger than the waste heat generated. It needs a power source of some kind of course to drive the refrigerator. Because you have a heat sink in the external iron, you can generate plenty of power.
And it melts faster than if there had been no refrigerator at all.
Let me guess, you're not real strong on thermodynamics? Please don't take up refrigerator design is all I can say.
Slashdot Mirror
Probably won't make much difference. In most places GTA is an 18 only game anyway. Selling it to underage kids is already illegal.
What happens to any universes that didn't rejoin with ours we can't tell for sure. However, a reasonable assumption seems to be that they still exist, and we have no reason to think that they don't. Most professional physicists believe in the many histories theory of quantum physics, which implies multiple universes.
A software renderer means that the software will still run, whereas the hardware we have right now will be gone.
Yeah they do. If it's a lot of time. If it's just more than it should have been in that scenario, then no, practically no profiler gives you any idea; it just gives you the average time spent in that routine, not the worst case AFAIK.
All I can say is that if the low priority of the GC makes your OS swap in that situation, then I would be very disappointed in that particular JVM, swapping is practically certain to slow the system down in the long run. It's a very common scenario to be continuously generating garbage, and the correct behaviour is for the garbage generating thread to try to allocate an object, fail, block and give the GC a chance to create some space and then carry on.
For example, I do not see how things would become much more dangerous in Java if you added a delete operator to complement the new operator. The operator would have the semantics that meant "delete, now". If you tried to access a deleted object, it would throw an exception.
It's likely to be difficult/slow to implement; the JVM would have to effectively hunt around for all the references to that object and null them out. That might well require searching every object in memory. And if it wasn't safe, then it becomes a security hole- above all Java was designed with safety in mind.
I said you can control the initial size of the memory. Many JVMs will normally not go outside that size unless it has already GCd and it still doesn't have enough memory.
I should be able to tell the GC that I am done with an object right here and now, rather than waiting for the low priority GC thread to take too long to pick it up.
Yes, that would certainly be useful; however, you can usually (depending on the VM) kick the GC off at sensible rates or tune the GC to run more often.
Still, there are alternatives; and I generally still prefer using Java inspite of these kinds of relatively minor shortfalls in the language because it is still a more powerful language than C++ (powerful in the sense of my programs being shorter in Java than C++).
Hey here's a thought. I'm not trying to troll, but could it be that you're rubbish at writing Java? Seriously? I mean Java isn't magic. If you don't have insight into what's happening, it will often run slowly- same thing happens with C/C++, it's just you are probably more familiar with those languages.
I've used Java on embedded applications, on systems that create lots, and lots of objects. And I don't recall ever running out of memory, if there wasn't a bug in the Java program.
But I'm not saying you're lying or wrong, only that a well tuned, well supported, JVM doesn't do this.
the opportunistic garbage collection of C/C++ simply leads to better performance than any language that tries to do the garbage collection for you.
What opportunistic garbage collection of C/C++? You mean delete and free? Get real! Personally, I wouldn't trust the average programmer to even collect garbage correctly more than half the time, and that doesn't cut it. I've had way, way less problems with Java GC than I've ever had with C/C++ in a realtime system. People have spent weeks finding memory leaks; and one time a leak I found was a ghastly C++ compiler bug where the compiler screwed up the automatic destructors on unnamed objects.
And when your CPU is spiked by an inner processing loop, the garbage collector which probably runs at a lower thread priority will not be given enough CPU to clear out memory fast enough.
For what exactly? The GC is supposed to free up ALL of the garbage (provided you have nulled the pointers). Anything else is a bug in the JVM; there certainly are bugs in just about any piece of software, including JVMs.
I believe that Hotspot only profiles the code for a while, and then switches off the profiling. The code runs a bit slowly for a short while as it is optimised and then runs at full speed.
Yeah, but that won't cause you to crash on any JVM I've ever used. What happens is it carries on allocating until it hits the limit and then starts GCing; the limit may well be megabytes- GCing takes a little while and many JVMs are tuned to avoid doing any GC if they don't have to (they benchmark better that way); but you can often adjust the JVM to GC much more often than that.
People dealing with time series data will use a time class. Anybody using these will definitely hate trading a zero-time stack allocation for a constant-time heap allocation. Put that in a loop and that becomes O (n) vs. zero. Add another loop and you get O (n^2) vs. again, zero.
What? A constant time operation in an 'n' loop is O(n), but then again, the loop is O(n) to start with. Add another loop and you get O(n^2) versus O(n^2). The constant of proportionality has changed, but that's all. If you were using C++, you'd probably call a constructor and possibly destructor anyway; so the difference is not nearly as much as you'd expect; and java heap allocation is only about 3 instructions anyway on a decent VM. This article is total junk.
Why, later, was Surak so slow?
It's because Surak has never written a line of Java in his life and simply trots out the same tired old message that he heard 4 years ago on Slashdot and repeats whenever Java comes up.
Surak is essentially regurgitating, inspite of JITs and JNIs actually writing pretty good machine code these days.
Suraks are slow. That's why people try to avoid hiring them.
Of course the fact that they don't do this, makes NASA a monopoly and gives it completely no incentive to clean up it's act; so in the long run, America in general, and American space in particular, is worse off.
Still, Boeing's SeaLaunch has pretty much done this. It doesn't look like a wild success at the moment, but it will hopefully improve.
Still, that would be speculation on my part, and I have no other evidence as to whether this is indeed happening at this company. It's not impossible that the people have indeed been slacking at their jobs, although from what I've seen of the evidence they do not seem to have been doing so in any significant way.
Yes, well, as a rule of thumb, european money only goes back to the country that invested it anyway (same thing happens with NASA), so I doubt it would have made that much difference.
But, 10% isn't that bad.
So, I don't think it's biological. I think it's more to do with stuff like spare time, having a drive to do something, looking at new material rather than being stuck doing the same thing all the time and so on; having children to look after etc. etc.
It's a software problem, not a hardware problem. And people can rewrite their software, and it gets rewritten by people around you all the time (although their are limits!)
There are lots of problems with scramjets. They've been a research project for decades and it's only in the last few years that one even gave positive thrust in real flight.
The problems with trying to survive at mach 6+ in thick atmosphere should not be underestimated, it is a far, far worse environment than the Shuttle faces when reentering (check out Columbia), and the Shuttle gets it over and done with as soon as possible, giving the heat less time to soak into the vehicle. A scramjet spends a lot longer going fast in thick atmosphere, and the temperature issues this causes on the outer skin is just awesome, never mind inside the scramjet itself.
The main thing that killed it, was the projected development cost- around $20 billion or more (and I think these are 1980 prices). The engines look like they would be really expensive to design, and they are the heart of the vehicle. Basically, he couldn't find anyone to fund it.
That's not actually true. A rocket produces about the same amount of pollution as burning the same amount of fuel in a car engine. The main pollutant it creates is CO2, and it doesn't, overall, produce any CO2 if you use biomass to make the rocket fuel (since the plants suck up as much CO2 as they grow as the rocket produces).
Yes, rocket propulsion is efficient in a chemical-kinetic energy transfer way, but not efficient if all other costs are taken into account.
Nonsense. It doesn't even use that much fuel. First, 2/3 of the fuel is liquid oxygen, it's cheap and environmentally friendly. That's produced from liquid distillation of air. That leaves about 20 kgs of fuel needed for each kg of payload. A person weighs, say 200 kg, including spacesuit. That means you need 4000kg of fuel. That's about the same amount of fuel as I burnt in my car last year. It's a lot, but not an overwhelming amount, and it's not like I go shopping in my rocket every day, going into space is a rare event.
Use geo-thermal energy to power such a mag-lev launcher thing... I find that preferable.
Yeah, but if you have the geo-thermal, why not use it to make hydrogen, and launch with that in a conventional rocket? That way you can do it for a few billion rather than 100 trillion dollars or whatever a 50km long mag-lev launcher would cost. How much pollution would be made in constructing that anyway?
No, you big dope. You don't generate energy by letting heat into the probe! You're right that's dumb, but I never suggested you do that.
You can generate energy by generating a hot reservoir above the external molten iron temperature and then running a heat engine between it and the outside, and then take the energy from that and run the refrigerator.
With that N watts of usable energy, you can transfer Y <= N watts of heat out of the probe. Y <= X. At 100% efficiency, the most heat you can transfer out is the heat you let in to generate the power in the first place. You cannot use heat flowing naturally from A->B to actively transfer a greater amount of heat from B->A. If that were possible, AC units would be self-powering.
Yeah, yeah. Trivial...
Good posting. However, that last point seems dubious, unless I've missed something stupid, but I don't think so.
If I had a 1 degree temperature difference on my hot sink, but a 50 degree temperature difference on my refrigerated section, I can still run the refrigerator to maintain the 50 degree difference if I allow a lot of heat flow to go between the hot sink and the cold sink, enough to run the refrigerator to maintain 50 degrees. You'll get really rotten efficiency with the generator section, but it works fine.
Admittedly the practical difficulties of the molten iron case are harder, but the maths is very much the same. If your kitchen refrigerator works, then so does one surrounded by molten iron, if designed correctly.
That kind of comment is more of a what you are doing to remove duplicates, rather than a why. I don't have any problem with that comment, it's an excellent comment. But if you had added a comment to the insertItem function to mention that they needed to be sorted so that the removeDuplicates worked properly, then that's not right, that's what documentation is for.
Yup. Nothing is 100% efficient. In fact there's a theoretical limit to how efficient it can be which is the Carnot cycle.
So, if we assume the refrigerator starts out at the same temperature as the rest of the probe, its temperature will rise above that of the probe, causing heat to flow from the refrigerator to the probe.
No. The waste heat flows out to the hot iron outside where it is conducted away.
This will cause the refrigerator to have to transfer more heat, which means more heat generation, and since the heat generated will always outpace the heat transfer, the probe melts.
No. The infinite series converges to a finite value, because the fraction of heat pumped is larger than the waste heat generated. It needs a power source of some kind of course to drive the refrigerator. Because you have a heat sink in the external iron, you can generate plenty of power.
And it melts faster than if there had been no refrigerator at all.
Let me guess, you're not real strong on thermodynamics? Please don't take up refrigerator design is all I can say.