"...might bring high power visual recognition to simple desktops and even mobile computers... computed in less than 20 seconds using nothing but a single, multi-core machine with 20GB of RAM."
Right... and by mobile computers you mean computers that I can lug from one desk to another.
Like the MacBook Pro Retina with 16 GB? The point of their approach seems to be lots and lots of RAM to do table lookups. The memory subsystem in a normal laptop is plenty fast for that. Bandwidth would be more of a problem than total space in a cellphone. If we had a compelling case for loads of RAM in a smartphone, it would be possible to design one without going wildly beyond current power or cost envelopes. A few more years of Moore and things will be fine.
Much like Windows 3.11 the GUI in GUN/Linux isn't a core part of the OS - but a graphics server with window managers on top and all the real work being done by the OS under the manager.
That is true, but the similarity doesn't go much further than that. If you look at the capabilities of the OS underneath, there is a major difference between Linux and DOS. (Even to this day some of the limitations inherited from DOS are still found in modern Windows versions. The last Windows user I came across wasn't able to open a command line window more than 80 characters wide.)
Yeah, opening the properties or using the MODE command is a terrible pain. By the way, Windows 3.1 in 386 mode didn't really put a fancy face on top of DOS. It is rather like a headcrab or something. It might rely on some of the services of the host, but it also modifies it beyond recognition. Virtual memory management and yes, some network services, lived almost solely in the Windows product, e.g. HIMEM.sys existed, but all the logic was in Windows.
DOS supported printing, in the sense that you could interface to a printer through LPT1. The way in which Apple and Microsoft worked towards abstracting the process of printing was a quite different thing. This could be a 3rd party library, but the point is that there is some brokering beyond the specific API, software, and specifications released by individual manufacturers.
A Pentium III-M or early Pentium M was far faster, on a clock by clock basis, than a single ARM core in most modern smartphones. They get ahead a bit by sporting multiple cores, but that won't help you much in Javascript, or in the really tricky parts of GCing in most VMs (not sure about Dalvik).
The 6502 was a 1MHz machine and floating point operations and even integer multiplication had to be done in software. How can a spreadsheet program designed for CPUs more than 2000 times faster with specialist floating point hardware be too slow? It must be shitty code.
It wouldn't be unlikely that there are more than 100,000 times as much data. Add to that automatic recalculation and graphic rendering. That said, I still consider the current performance tragic.
What a small,sterile little world you live in, where the only source of genetic material in a child is its mother and father. Do a little bit of research on viruses, especially retroviruses, and horizontal gene transfer.
The likelihood of that being the culprit in any specific case is abysmal. Now, it seems like this girl has a de novo mutation, but most likely one due to traditional errors in the replication machinery, or chemical modification. While viral activity and HGT are important to recognize in the evolutionary tree as a whole, they are not critical to everyday mundane genetic variability.
Asymmetric encryption (like all sane network protocols rely on) does not require secure key exchange. However, NSA has had more than one finger in the development of the schemes actually used, for hashing, encryption and handshaking protocols, so it is hard to exclude a backdoor. And, of course, you need to assume that both terminals are secure. And depending on what CAs you trust, the point might be moot.
On one hand you have the public backlash if/when an attack succeeds due to inadequate intelligence gathering.
I'll take my chances. Statistically this century I've had a greater chance of drowning in my bathtub than being an American killed by a terrorist. And no, that's not evidence that the spying is working.
It's evidence that bathroom surveillance is not what it should be (or at least not used properly).
Well, for a Mac Pro an "upgrade" could also mean simply not ordering your full storage or memory needs from Apple in the first place, but opening the case the minute you receive it to put in whatever parts you really wanted to use.
According to most people, a Dell I used didn't make any noise either. I am pretty confident that it did (i.e. blind tests on plugged in or not correlating with my opinion on whether it was plugged in, eyes closed and laptop tucked away). Just like the opinion on whether specific CRTs squealed or not at specific display settings can differ quite a bit depending your hearing and sensitivity to such noises.
I wouldn't agree. The out of order depth has increased in later architectures, but not by that much. Rather, branch prediction is better, so we have fewer mis-predicts. We have wider execution units (thus necessitating the higher depth), but that's a "real" improvement in performance. The number of instructions retired per clock under ideal conditions per core, is higher. Hyperthreading has been kept, but it is implemented in a smarter manner with a more dynamic sharing of resources. All of this is happening in the area of "fat" cores and naturally we are reaching some point where there is little more that can be done, but typical energy use under idle and modest load has been decreasing, not increasing. If you just want the performance of a 65 W Core 2 Duo, you can certainly get that out of the new 35 W desktop SKU and get pretty close to it with the 17 W laptop ones under most conditions as well. It is "only" a decrease by 50-75 % in 6 years or so, but it is far from "nothing changes". And, yeah, by the way, you get integrated graphics within that 35 W TDP as well.
Of course we should use instruction sets that are available. However, I think you need to defend your point on the compiler issue. Most precompiled software is optimized for a pretty old common target. I would be highly surprised if default code emitted by e.g. GCC is slower on a Core now, than it was five years ago. This is also due to the fact that Conroe all the way to Haswell share so many characteristics. Netburst vs. Core entailed far more cases where you would actually prefer differences in emitted code, even for basic things. The relative costs of that pipeline were huge.
But when it comes to general performance improvement it's rather disappointing. Looks like they have fine tuned the current architecture without actually adding something that increases the performance at the same rate as we have seen the last decades. To some extent it looks like we have hit a ceiling in increased performance with the current overall computer architecture and that new approaches are needed. The clock frequency is basically the same as for the decade old P4, the number of running cores on a chip seems to be limited too, at least compared to other architectures.
Even single-threaded performance, even if you normalize for identical frequencies, has increased since Core 2. That they have increased since Pentium 4 goes without saying. We do not see the same increases in instructions per second that we used to do, but we still have increases. This page (and the next) from Anandtech was quite illuminating.
Well, we do have Mercury and Venus in our system and that hasn't hurt us, has it? (Yeah, Mercury is small, but Venus is also on the too-close side even without greenhouse gases and almost Earth-size.)
I guess the point with Kepler is still that due to the methodology (repeated occlusions), shorter orbital periods will increase the chance of detection (more data points to establish significance), in addition to the fact that a planet closer to its host star will occlude a larger area and thus give a stronger signal. Just keeping Kepler going will increasingly shift the distribution of detected planets towards higher star-planet distances. The minimum detectable size will be more or less of a constant function of that distance, though, although again I guess repeated observations can sometimes bring out something that would otherwise be just at the noise floor.
For reference, Kepler has just completed 4 years of operation, but actual planet detection only started on May 12 2009. If you want three confirmed events, you could per definition not yet have detected e.g. an exo-Mars. It simply hasn't passed by three times yet. If the orbital plane is different, the planet might not pass in our line of sight every time, and then working out the period and get a detection can take even longer.
Please tell me more about optimizing games to be properly multithreaded will only last few months and then be outdated.
The point made by the GP to your post was that the supplier of console chips would have an advantage in other markets. That advantage won't last long, since architectures evolve. Something heavily optimized for a 2005-era ATI chip will be peanuts for any chip to handle today, and general developer awareness of architecture detail is almost as useless. Both AMD and Nvidia have switched overall design philosophies over that timespan and made semi-radical changes several times beyond that.
True, but now when you know where to look, it is far easier to retrofit proper theory. The presence of the solutions could trivially be verified in any (really well-written) independent numerical simulation.
would anyone care to explain how much accurate are the numerical analysis/numerical integration solutions ?
They are as accurate as you care to make them. The problem is that increased accuracy over a long period can
require an exponential increase in cost.
Does the accuracy depend on how small is the dt we chose between each calculation ?
Precisely.
Well, for the same solver, it does. But the relative (and absolute) improvement realized by changing dt is quite dependent on what solver scheme you are using.
Many computer systems have been created with education of computer science concepts in mind (or at least as an important design goal). Pascal and BASIC were to a varying degree created with this purpose in mind (Dr. Jekyll and Mr. Hyde, if you will...). During the microcomputer revolution, they became the de facto norm. Only far later did C intrude to a significant extent into that market.
incidentally Google Glass has very little to do with AR. Its just a transparent 320x200 (or less) resolution display with camera for your phone:/
Having a display at a constant spot in your field of view, and a camera perfectly aligned with your field of view, doesn't give you possibilities to quite immersively augment your perception of reality? Come again?
Process A calls kernel. That's okay, kernel-userspace transitions can be reasonably fast. Function called is actually implemented in userspace process B. Whoa, context switch. You can easily have a 100x slowdown in your kernelspace interpreter and still come out ahead compared to incurring that context switch. This all assuming that the driver will not do a lot of complicated processing. Rather, it will probably just need to check some basic data structures to identify whether the operation is currently allowed and maintain some shared state between processes. (Not) surprisingly enough, that's all there is to many drivers. I would even think that some file systems currently implemented in FUSE would be faster using a reasonably well-behaving "safe" kernel language.
Name the products, which will of course also tell us the companies. However, it is very hard to evaluate this in general terms. A flash operation can always go wrong. If the updated code expliclitly recommended by the vendor was in fact incompatible, then I think they are at fault to some extent even for out-of-warranty hardware. But that's the only case.
Slashdot Mirror
"...might bring high power visual recognition to simple desktops and even mobile computers... computed in less than 20 seconds using nothing but a single, multi-core machine with 20GB of RAM."
Right... and by mobile computers you mean computers that I can lug from one desk to another.
Like the MacBook Pro Retina with 16 GB? The point of their approach seems to be lots and lots of RAM to do table lookups. The memory subsystem in a normal laptop is plenty fast for that. Bandwidth would be more of a problem than total space in a cellphone. If we had a compelling case for loads of RAM in a smartphone, it would be possible to design one without going wildly beyond current power or cost envelopes. A few more years of Moore and things will be fine.
The article, as in scientific paper, is quite clear on this. There is no signs that anything close to vertebrates are infectable.
RTFA, they believe the size makes it look like juicy food.
That is true, but the similarity doesn't go much further than that. If you look at the capabilities of the OS underneath, there is a major difference between Linux and DOS. (Even to this day some of the limitations inherited from DOS are still found in modern Windows versions. The last Windows user I came across wasn't able to open a command line window more than 80 characters wide.)
Yeah, opening the properties or using the MODE command is a terrible pain. By the way, Windows 3.1 in 386 mode didn't really put a fancy face on top of DOS. It is rather like a headcrab or something. It might rely on some of the services of the host, but it also modifies it beyond recognition. Virtual memory management and yes, some network services, lived almost solely in the Windows product, e.g. HIMEM.sys existed, but all the logic was in Windows.
DOS supported printing, in the sense that you could interface to a printer through LPT1. The way in which Apple and Microsoft worked towards abstracting the process of printing was a quite different thing. This could be a 3rd party library, but the point is that there is some brokering beyond the specific API, software, and specifications released by individual manufacturers.
A Pentium III-M or early Pentium M was far faster, on a clock by clock basis, than a single ARM core in most modern smartphones. They get ahead a bit by sporting multiple cores, but that won't help you much in Javascript, or in the really tricky parts of GCing in most VMs (not sure about Dalvik).
Visicalc on the Commodore Pet.
The 6502 was a 1MHz machine and floating point operations and even integer multiplication had to be done in software. How can a spreadsheet program designed for CPUs more than 2000 times faster with specialist floating point hardware be too slow? It must be shitty code.
It wouldn't be unlikely that there are more than 100,000 times as much data. Add to that automatic recalculation and graphic rendering. That said, I still consider the current performance tragic.
Go look up the DirectX story on Windows NT. The NT-level OSes have always had some level of uncertainty regarding what DX will be back-ported or not.
What a small,sterile little world you live in, where the only source of genetic material in a child is its mother and father. Do a little bit of research on viruses, especially retroviruses, and horizontal gene transfer.
The likelihood of that being the culprit in any specific case is abysmal. Now, it seems like this girl has a de novo mutation, but most likely one due to traditional errors in the replication machinery, or chemical modification. While viral activity and HGT are important to recognize in the evolutionary tree as a whole, they are not critical to everyday mundane genetic variability.
Asymmetric encryption (like all sane network protocols rely on) does not require secure key exchange. However, NSA has had more than one finger in the development of the schemes actually used, for hashing, encryption and handshaking protocols, so it is hard to exclude a backdoor. And, of course, you need to assume that both terminals are secure. And depending on what CAs you trust, the point might be moot.
On one hand you have the public backlash if/when an attack succeeds due to inadequate intelligence gathering.
I'll take my chances. Statistically this century I've had a greater chance of drowning in my bathtub than being an American killed by a terrorist. And no, that's not evidence that the spying is working.
It's evidence that bathroom surveillance is not what it should be (or at least not used properly).
Well, for a Mac Pro an "upgrade" could also mean simply not ordering your full storage or memory needs from Apple in the first place, but opening the case the minute you receive it to put in whatever parts you really wanted to use.
According to most people, a Dell I used didn't make any noise either. I am pretty confident that it did (i.e. blind tests on plugged in or not correlating with my opinion on whether it was plugged in, eyes closed and laptop tucked away). Just like the opinion on whether specific CRTs squealed or not at specific display settings can differ quite a bit depending your hearing and sensitivity to such noises.
I wouldn't agree. The out of order depth has increased in later architectures, but not by that much. Rather, branch prediction is better, so we have fewer mis-predicts. We have wider execution units (thus necessitating the higher depth), but that's a "real" improvement in performance. The number of instructions retired per clock under ideal conditions per core, is higher. Hyperthreading has been kept, but it is implemented in a smarter manner with a more dynamic sharing of resources. All of this is happening in the area of "fat" cores and naturally we are reaching some point where there is little more that can be done, but typical energy use under idle and modest load has been decreasing, not increasing. If you just want the performance of a 65 W Core 2 Duo, you can certainly get that out of the new 35 W desktop SKU and get pretty close to it with the 17 W laptop ones under most conditions as well. It is "only" a decrease by 50-75 % in 6 years or so, but it is far from "nothing changes". And, yeah, by the way, you get integrated graphics within that 35 W TDP as well.
Of course we should use instruction sets that are available. However, I think you need to defend your point on the compiler issue. Most precompiled software is optimized for a pretty old common target. I would be highly surprised if default code emitted by e.g. GCC is slower on a Core now, than it was five years ago. This is also due to the fact that Conroe all the way to Haswell share so many characteristics. Netburst vs. Core entailed far more cases where you would actually prefer differences in emitted code, even for basic things. The relative costs of that pipeline were huge.
But when it comes to general performance improvement it's rather disappointing. Looks like they have fine tuned the current architecture without actually adding something that increases the performance at the same rate as we have seen the last decades. To some extent it looks like we have hit a ceiling in increased performance with the current overall computer architecture and that new approaches are needed. The clock frequency is basically the same as for the decade old P4, the number of running cores on a chip seems to be limited too, at least compared to other architectures.
Even single-threaded performance, even if you normalize for identical frequencies, has increased since Core 2. That they have increased since Pentium 4 goes without saying. We do not see the same increases in instructions per second that we used to do, but we still have increases. This page (and the next) from Anandtech was quite illuminating.
Well, we do have Mercury and Venus in our system and that hasn't hurt us, has it? (Yeah, Mercury is small, but Venus is also on the too-close side even without greenhouse gases and almost Earth-size.)
I guess the point with Kepler is still that due to the methodology (repeated occlusions), shorter orbital periods will increase the chance of detection (more data points to establish significance), in addition to the fact that a planet closer to its host star will occlude a larger area and thus give a stronger signal. Just keeping Kepler going will increasingly shift the distribution of detected planets towards higher star-planet distances. The minimum detectable size will be more or less of a constant function of that distance, though, although again I guess repeated observations can sometimes bring out something that would otherwise be just at the noise floor.
For reference, Kepler has just completed 4 years of operation, but actual planet detection only started on May 12 2009. If you want three confirmed events, you could per definition not yet have detected e.g. an exo-Mars. It simply hasn't passed by three times yet. If the orbital plane is different, the planet might not pass in our line of sight every time, and then working out the period and get a detection can take even longer.
Just wait and see.
Please tell me more about optimizing games to be properly multithreaded will only last few months and then be outdated.
The point made by the GP to your post was that the supplier of console chips would have an advantage in other markets. That advantage won't last long, since architectures evolve. Something heavily optimized for a 2005-era ATI chip will be peanuts for any chip to handle today, and general developer awareness of architecture detail is almost as useless. Both AMD and Nvidia have switched overall design philosophies over that timespan and made semi-radical changes several times beyond that.
True, but now when you know where to look, it is far easier to retrofit proper theory. The presence of the solutions could trivially be verified in any (really well-written) independent numerical simulation.
would anyone care to explain how much accurate are the numerical analysis/numerical integration solutions ?
They are as accurate as you care to make them. The problem is that increased accuracy over a long period can require an exponential increase in cost.
Does the accuracy depend on how small is the dt we chose between each calculation ?
Precisely.
Well, for the same solver, it does. But the relative (and absolute) improvement realized by changing dt is quite dependent on what solver scheme you are using.
The article was about a biochemical pathway, and a mouse model. People didn't enter into the immediate evidence.
Many computer systems have been created with education of computer science concepts in mind (or at least as an important design goal). Pascal and BASIC were to a varying degree created with this purpose in mind (Dr. Jekyll and Mr. Hyde, if you will...). During the microcomputer revolution, they became the de facto norm. Only far later did C intrude to a significant extent into that market.
incidentally Google Glass has very little to do with AR. Its just a transparent 320x200 (or less) resolution display with camera for your phone :/
Having a display at a constant spot in your field of view, and a camera perfectly aligned with your field of view, doesn't give you possibilities to quite immersively augment your perception of reality? Come again?
Process A calls kernel. That's okay, kernel-userspace transitions can be reasonably fast. Function called is actually implemented in userspace process B. Whoa, context switch. You can easily have a 100x slowdown in your kernelspace interpreter and still come out ahead compared to incurring that context switch. This all assuming that the driver will not do a lot of complicated processing. Rather, it will probably just need to check some basic data structures to identify whether the operation is currently allowed and maintain some shared state between processes. (Not) surprisingly enough, that's all there is to many drivers. I would even think that some file systems currently implemented in FUSE would be faster using a reasonably well-behaving "safe" kernel language.
Name the products, which will of course also tell us the companies. However, it is very hard to evaluate this in general terms. A flash operation can always go wrong. If the updated code expliclitly recommended by the vendor was in fact incompatible, then I think they are at fault to some extent even for out-of-warranty hardware. But that's the only case.