C++ compilers cannot improve in this regard. Thier performance is determined by the underlying OS allocation mechaisms. Yep, Malloc normally involves a context switch into the kernel (slow) and then has to search for a free block large enough to hold your request. Compare that to java that does little more then increment a pointer in its most common call path.
And if you had read the article you would have seen that your first example can and in applicable circumstances, will be converted to your second example by the JVM (as long as it does not break the logic behind the encapsulation you placed there). In fact the article explicitly says how this can occur. All this while still maintaining robust and reliable code.
No need to break encapsulation or compromise on design to get a performance increase. The VM will perform that optimisation for you while allowing you to write well structured and maintainable code.
I do think you have a point. Generalization, object oriented design, well structured, reliable and reusable software do all tend to impact performance. Its nice that the performance can be reclaimed by "hotspot" compilers rather then having to compromise your design for the sake of performance.
"Stop the world" is necessary on multicore CPUs, however it happens very rarely.
Most VM's will split the new generation between the "threads" (ie a thread local memory and associated GC). The the thread can allocate its own local memory and only synch when necessary.
Java is often prefered for multi cpu systems as it has a very well defined threading mechanism as part of the language. That means a multithreaded app is portable (and performant).
Thats why you have the option of putting up a little sign that says "one plate at a time please". You CAN specify how much or little memory a java app uses (an even how the garbage collector works) but you don't HAVE to.
And when resources get really tight C is no longer an appropriate language to use. Many microcontrollers have less then 128 bytes of ram to work in. Often the program has to be stored in less then 256 bytes of ROM. C does not cut it in those environments. Welcome to our assembler overlords. C also has to be cut down to run on these low end devices. floating point divisions, 32 bit mulitplications, 16 bit additions...well they are not supported. The J2ME IS cut down. However it does specify a basic set of operations you must implement on the chip (or emulate in a layer in software)
"Remember, with Java you still have the overhead of a virtual machine. And that counts towards program and resource size (sometimes, significantly)."
The processors I'm playiung with at the moment run java byte code natively. You would have to have a virtual machine to run C on them. Rememeber, C is only efficient in some situations because the bytecode (machine code) it produces maps directly to the platform it is running on. Java and other "interpreted" langauges are designed to run on a machine that you may not have, so generally they are run on an interpreter. That does not mean that a machine to run the code directly does not exist.
The UN is a democracy of nations. It does not go any further than that. How a government is elected is mostly beyond the remit of the UN (unless enough constiuents (ie nation states) object)
"The U.N. was not designed to regulate what most would consider a utility"
Yep, you are correct. The UN was not created to run a "utility". The UN is supposed to be a democracy of nations. A place where nations argue and battle to determine how international agreements will work.
There are over 130 nation states in the UN yet many Americans appear to think that unless the UN agrees with them then the UN is wrong or ineffectual.
When the UN does not solve a problem it is because the members do not want to, or cannot agree on how to. Welcome to democracy... not everything goes your way.
You do realise that the arms inspectors where never chartered with "proving that Iraq did not have chemical and biological weapons". That is impossible to do.
You cannot prove a negative theory. According to you the UN send arms inspectors to Iraq to prove that something did not exist? They were sent to see if there WAS any evidence of C or B Weapons. They found no evidence.
It is a proven fact that over ten years ago Iraq did have chemical weapons (when they last used them). Since then there has been no eveidence that Iraq has any ability to produce or has any large stockpiles of chemical or biological weapons.
A ground-breaking discovery usually confers little to no "benefit to humanity" in the year it is made. Sometimes it does take decades for humanity to benefit from the discovery (and more importantly prove the discovery is valid).
If the awards were given out in the manner you recommend then the two new Lauriates would never have received thier prizes. Thier discovery was not recognised in the year they made it. Just because it takes a long time to convince the medical comunity that your discovery is valid should not mean that you are inelegible for a prize.
Wouldn't it be irritating if two amazing, world changing discoveries, were made in the same field in the same year (a cure for cancer and a vaccine for AIDS perhaps). Who would you pick? The way they currently allocate the awards they have a degree of flexibility
I like open source software but much (most) of it is so badly documented as to be almost useless.
I do not think you should have to read to source code to find out how to call a method. You should only need to do that if you find a problem when you try to call the method the way the specification (or even comments...if there are any) says it should be called. Much of the available software (In particular I mean you Apache) is like this (ie very badly documented). A higher level of documentation is also necessary: the stuff that explains, in general terms, how to use the apis provided. This is also a specification of a sort.
I think the worst culprits are the specifications designed by committie (generally a committie trying to improve on a previous spec). Invariably the previous spec was reverse engineered from the current world (what is actually being used). The new spec is then made to be backward compatible (i.e. it includes all of the worst aspects of the orignial spec) and also tries to add the pet feature of every body involved in the committie. HTTP 1.1, CSS 2 and 3, xpath 2, etc are all instances of this. Nobody can implement any of these correctly because they are so complicated they cannot be specified correctly (or completely). Therefore each generation of the spec gets abused by everybody as the spec can be interpreted in different ways. Then the next generation is designed by a committie and has to handle all of the bastardized approaches that the previous spec allowed and in addition add a plethora of new features (many of which will never be used).
Most new specs are designed to be extensible. This means they should also be simple as specialist domains can add thier own extensions as needed and develop thier own specs. However this never seems to be the case. The spec tirs to include everything.
Specs derived from implementations tend to be far more reliable as they are: a) simple. They generally only specify the functionailty that is needed to perform the task b) tested. They are derived from a working example taht has already overcome many if not most of the problems that need to be solved.
While the US is nominally the largest contributer to the UN it has an amazing proclivity to default on its payments. It is currently estimated to owe 1.2 billion to the UN. Thats equivelent to 2 complete years of US's required contribution.
And if you did not know it America is only required to pay 2 percent more year then Japan is. If you combine the UK, France and Germany then they pay more then the US but have a significantly lower population. So, no, america does not pay for the UN.
As for "The UN has been unable to enforce international copyright law and patent law." had you even contemplated the idea of the other 130 members of the UN not actually wanting to enfore international copyright and patent law in the manner the US wishes. That could well be the reason why the UN has not had much success with the agenda of the US in this area.
More interestingly is the fact that even specialized hardware does not provide you with absolute security (especially if the hardware is an open standard). All hardware can be emulated in software. If you know how the hardware is supposed to behave then you can emulate it. If you can emulate it then you have bypassed any security advantages it provided.
You just need to ensure you are running your emulator when you sign up to license the latest and greatest album/movie/whatever and your copy will be registered against virtual hardware keys.
The only ways you could potentially stop this kind of attack are: a) Legal (DMCA for example) b) centralized authentication (might work as long as all known hardware keys are registered and none are ever obtained directly from the hardware and put into emulation software)
I believe that the problem is not with disposal of the rods. It is with the large quantities of low grade waste produced by the power station. Pretty much all of the consumables used by staff in the station are classified as radioactive waste. Then there is the problem of disposing of the station itself. Pretty much all of it is classified as radioactive waste.
There is a lot of steel in a power station. Almost none of it can be recycled because it is mildly radioactive.
Most of this stuff is probably not particularly harmful but costs a huge amount to dispose of.
Sun's implementation of java is open source. The source for the runtime is included in the jdk. The source for the VM (1.5 only) is available on their web site. You can do what you want with it as long as you do not distribute your changes. If you want ot distribute your changes you have to contribute them back to Sun (Under a shared copyright agreement).
I think you ment that it is not released as open source under your favortie license.
You are not thinking about the baseline seperation of the camera needed to achive an accurate depth resolution. One camera pointing straight down and sampled at time t0 and again at time t1 could be used to generate a depth map. However as your requirements for the accuracy of the depth map increase then the time difference between t0 and t1 must become larger. Above a certain value then the images taken at t0 and at t1 will not overlap.
Having one camera looking forward and down (along the flightpath of the sat and one pointing down at back enable you to take two pictures of the same area of land when the difference between t0 and t1 is very large (not too large or perspetive distortion will bugger up your attempts to create a depth map)
Big O notation is still relevent. You just have to remeber that it has never been able to tell you which algorithm is "faster". It only ever tells you how an algorithm scales with its dataset.
Cache hits, branch mispredictions et al have a constant upper bound for the worst case performance they can cause and it is not dependent on the size of the data set. That means it is a constant in Big O notation.
Big O notation is generally useless for small datasets but then for small datasets you often don't care about the performance as it is sufficiently fast. If not you have to profile.
Slashdot Mirror
C++ compilers cannot improve in this regard. Thier performance is determined by the underlying OS allocation mechaisms. Yep, Malloc normally involves a context switch into the kernel (slow) and then has to search for a free block large enough to hold your request.
Compare that to java that does little more then increment a pointer in its most common call path.
And if you had read the article you would have seen that your first example can and in applicable circumstances, will be converted to your second example by the JVM (as long as it does not break the logic behind the encapsulation you placed there). In fact the article explicitly says how this can occur. All this while still maintaining robust and reliable code.
No need to break encapsulation or compromise on design to get a performance increase. The VM will perform that optimisation for you while allowing you to write well structured and maintainable code.
I do think you have a point. Generalization, object oriented design, well structured, reliable and reusable software do all tend to impact performance. Its nice that the performance can be reclaimed by "hotspot" compilers rather then having to compromise your design for the sake of performance.
"Stop the world" is necessary on multicore CPUs, however it happens very rarely.
Most VM's will split the new generation between the "threads" (ie a thread local memory and associated GC). The the thread can allocate its own local memory and only synch when necessary.
Java is often prefered for multi cpu systems as it has a very well defined threading mechanism as part of the language. That means a multithreaded app is portable (and performant).
Thats why you have the option of putting up a little sign that says "one plate at a time please". You CAN specify how much or little memory a java app uses (an even how the garbage collector works) but you don't HAVE to.
And when resources get really tight C is no longer an appropriate language to use. Many microcontrollers have less then 128 bytes of ram to work in. Often the program has to be stored in less then 256 bytes of ROM. C does not cut it in those environments. Welcome to our assembler overlords. C also has to be cut down to run on these low end devices. floating point divisions, 32 bit mulitplications, 16 bit additions...well they are not supported. The J2ME IS cut down. However it does specify a basic set of operations you must implement on the chip (or emulate in a layer in software)
"Remember, with Java you still have the overhead of a virtual machine. And that counts towards program and resource size (sometimes, significantly)."
The processors I'm playiung with at the moment run java byte code natively. You would have to have a virtual machine to run C on them. Rememeber, C is only efficient in some situations because the bytecode (machine code) it produces maps directly to the platform it is running on. Java and other "interpreted" langauges are designed to run on a machine that you may not have, so generally they are run on an interpreter. That does not mean that a machine to run the code directly does not exist.
The UN is a democracy of nations. It does not go any further than that. How a government is elected is mostly beyond the remit of the UN (unless enough constiuents (ie nation states) object)
When was the last time the US let UN inspectors assess US complience with nuclear, chemical and biological control treaties?
"The U.N. was not designed to regulate what most would consider a utility"
... not everything goes your way.
Yep, you are correct. The UN was not created to run a "utility". The UN is supposed to be a democracy of nations. A place where nations argue and battle to determine how international agreements will work.
There are over 130 nation states in the UN yet many Americans appear to think that unless the UN agrees with them then the UN is wrong or ineffectual.
When the UN does not solve a problem it is because the members do not want to, or cannot agree on how to.
Welcome to democracy
You do realise that the arms inspectors where never chartered with "proving that Iraq did not have chemical and biological weapons". That is impossible to do.
You cannot prove a negative theory. According to you the UN send arms inspectors to Iraq to prove that something did not exist? They were sent to see if there WAS any evidence of C or B Weapons. They found no evidence.
It is a proven fact that over ten years ago Iraq did have chemical weapons (when they last used them). Since then there has been no eveidence that Iraq has any ability to produce or has any large stockpiles of chemical or biological weapons.
A ground-breaking discovery usually confers little to no "benefit to humanity" in the year it is made. Sometimes it does take decades for humanity to benefit from the discovery (and more importantly prove the discovery is valid).
If the awards were given out in the manner you recommend then the two new Lauriates would never have received thier prizes. Thier discovery was not recognised in the year they made it. Just because it takes a long time to convince the medical comunity that your discovery is valid should not mean that you are inelegible for a prize.
Wouldn't it be irritating if two amazing, world changing discoveries, were made in the same field in the same year (a cure for cancer and a vaccine for AIDS perhaps). Who would you pick? The way they currently allocate the awards they have a degree of flexibility
Welcome to the joys of open source!
I like open source software but much (most) of it is so badly documented as to be almost useless.
I do not think you should have to read to source code to find out how to call a method. You should only need to do that if you find a problem when you try to call the method the way the specification (or even comments...if there are any) says it should be called. Much of the available software (In particular I mean you Apache) is like this (ie very badly documented). A higher level of documentation is also necessary: the stuff that explains, in general terms, how to use the apis provided. This is also a specification of a sort.
cheers
matfud
Hear hear,
I think the worst culprits are the specifications designed by committie (generally a committie trying to improve on a previous spec). Invariably the previous spec was reverse engineered from the current world (what is actually being used). The new spec is then made to be backward compatible (i.e. it includes all of the worst aspects of the orignial spec) and also tries to add the pet feature of every body involved in the committie. HTTP 1.1, CSS 2 and 3, xpath 2, etc are all instances of this. Nobody can implement any of these correctly because they are so complicated they cannot be specified correctly (or completely). Therefore each generation of the spec gets abused by everybody as the spec can be interpreted in different ways. Then the next generation is designed by a committie and has to handle all of the bastardized approaches that the previous spec allowed and in addition add a plethora of new features (many of which will never be used).
Most new specs are designed to be extensible. This means they should also be simple as specialist domains can add thier own extensions as needed and develop thier own specs. However this never seems to be the case. The spec tirs to include everything.
Specs derived from implementations tend to be far more reliable as they are:
a) simple. They generally only specify the functionailty that is needed to perform the task
b) tested. They are derived from a working example taht has already overcome many if not most of the problems that need to be solved.
Cheers
Matfud
While the US is nominally the largest contributer to the UN it has an amazing
proclivity to default on its payments. It is currently estimated to owe
1.2 billion to the UN. Thats equivelent to 2 complete years of US's required contribution.
And if you did not know it America is only required to pay 2 percent more year then Japan is. If you combine the UK, France and Germany then they pay more then the US but have a significantly lower population. So, no, america does not pay for the UN.
As for "The UN has been unable to enforce international copyright law and patent law." had you even contemplated the idea of
the other 130 members of the UN not actually wanting to enfore international copyright and patent law in the manner the US wishes.
That could well be the reason why the UN has not had much success with the agenda of the US in this area.
Cheers
matfud
You will not get "proper professional waiters" until waiters get paid "proper professional wages"
More interestingly is the fact that even specialized hardware does not provide you with absolute security (especially if the hardware is an open standard). All hardware can be emulated in software. If you know how the hardware is supposed to behave then you can emulate it. If you can emulate it then you have bypassed any security advantages it provided.
You just need to ensure you are running your emulator when you sign up to license the latest and greatest album/movie/whatever and your copy will be registered against virtual hardware keys.
The only ways you could potentially stop this kind of attack are:
a) Legal (DMCA for example)
b) centralized authentication (might work as long as all known hardware keys are registered and none are ever obtained directly from the hardware and put into emulation software)
matfud
my reading comprehension needs work
I believe that the problem is not with disposal of
the rods. It is with the large quantities of low
grade waste produced by the power station. Pretty
much all of the consumables used by staff in the
station are classified as radioactive waste. Then
there is the problem of disposing of the station
itself. Pretty much all of it is classified as
radioactive waste.
There is a lot of steel in a power station. Almost
none of it can be recycled because it is mildly
radioactive.
Most of this stuff is probably not particularly
harmful but costs a huge amount to dispose of.
matfud
Um, the French do have nuclear weapons. They refused
to sign the CTBT until they had finished a blowing
up atols in the pacific in 1996.
The java runtime can be freely distributed as long as it is packaged with an application (OO for example).
Admittedly this get a bit storage heavy if you try to distribute a large number of apps written in java.
The source for the 1.5 VM from sun is available you just have to download it.
Sun's implementation of java is open source. The source for the runtime is included in the jdk. The source for the VM (1.5 only) is available on their web site. You can do what you want with it as long as you do not distribute your changes. If you want ot distribute your changes you have to contribute them back to Sun (Under a shared copyright agreement).
I think you ment that it is not released as open source under your favortie license.
matfud
You are not thinking about the baseline seperation
of the camera needed to achive an accurate depth
resolution. One camera pointing straight down and
sampled at time t0 and again at time t1 could be used
to generate a depth map. However as your requirements
for the accuracy of the depth map increase then the
time difference between t0 and t1 must become
larger. Above a certain value then the images
taken at t0 and at t1 will not overlap.
Having one camera looking forward and down (along
the flightpath of the sat and one pointing down at
back enable you to take two pictures of the same
area of land when the difference between t0 and t1
is very large (not too large or perspetive
distortion will bugger up your attempts to create
a depth map)
IBM released its dual core POWER4 (powerPC 970) processors in 2001 sun followed shortly after with the ultraIV
You mean in the period of time AFTER america helped overthrow the government there but before it invaded to free the people it had helped to enslave?
Big O notation is still relevent. You just have to remeber that it has never been able to tell you which algorithm is "faster". It only ever tells you how an algorithm scales with its dataset.
Cache hits, branch mispredictions et al have a constant upper bound for the worst case performance they can cause and it is not dependent on the size of the data set. That means it is a constant in Big O notation.
Big O notation is generally useless for small datasets but then for small datasets you often don't care about the performance as it is sufficiently fast. If not you have to profile.