when they were being measured, i believe the statistics were somewhere around 300+ per month. at over 3 years of development at the time, that would easily exceed 10,000 commits. if i had continued on the project, at that rate, the number of commits would be somewhere exceeding 70,000. rapid and proper incremental code development is like that.
cash, which can be transferred from person to person, is untraceable and unstoppable. each person transfers cash by means of physically moving their arms, holding the cash in their hand, and dropping into the hand of the next person.
the list of functionality sounds like a perfect recipe for absolutely every major software company under the sun to begin anti-trust lawsuits, to me. oh, and patent infringement cases, too...
yes, that's absolutely correct - your conclusion is, however ("what a load of nonsense") completely wrong. to illustrate, you have to bear in mind that all modern CISC processors have, at their core, a RISC processor underneath. the "CISC" part simply provides an on-board translator from the complex to the reduced instruction set.
as to the rest, i'm not sure how to tell you that it doesn't matter if the processor does complex work, really slowly, or does simple work, really quickly: in the end, the results are still obtained, but in the "simple" case, you get the benefit of having far less silicon, and thus far less power used.
of much more serious concern - to google - is the fact that they are *knowingly* not pursuing GPL Copyright Infringement cases against Android-Linux GPL violators. if you fail to pursue a Copyright violation, it can be argued that you have "no interest" in protecting the Copyrighted material. as it is not in google's interests to pursue copyright violations because that would reduce the number of google android systems in the world, thus affecting their bottom line by reducing advertising income, they're in a bit of shit.
of much more serious concern - to google - is the fact that they are *knowingly* not pursuing GPL Copyright Infringement cases against Android-Linux GPL violators. if you fail to pursue a Copyright violation, it can be argued that you have "no interest" in protecting the Copyrighted material. as it is not in google's interests to pursue copyright violations because that would reduce the number of google android systems in the world, thus affecting their bottom line by reducing advertising income, they're in a bit of shit.
it's not that they're 32-bit or 64-bit that's so important, it's that until the Cortex A9, you couldn't use ECC RAM. also, with only 32-bit memory addressing, and with peripherals memory-mapped, many ARM SoCs simply can't do more than 1gb RAM (and many Cortex A9s can't do more than 2gb). then, also, there is the lack of virtualisation, which, again, has only been corrected in the Cortex A9 design.
"low power" quad-core 65nm 1ghz MIPS64 chips use 10 watts; 90nm, 20 watts. if you go to 28nm and stay at 1ghz, you divide by four - so that's 10/4 = 2.5 watts.
also, there are two different configurations for 65nm done by TSMC: one is high-performance (lower cost, 20 masks) and the other is lower-power (slightly higher cost, 32 masks). the lower-power CMOS one was only invented recently, so this is why you often see e.g. Broadcom Network / Server MIPS64 Quad-Core 1ghz 65nm CPUs consuming 10-20 watts. with the mask charges (NREs) being measured in $millions and the verification as well it's not justifiable financially to do a conversion of these older ICs to the newer lower-power fab process.
so there are a lot of factors that need to be taken into consideration. also you have to bear in mind that speed is a trade-off against latency. ARM SoCs are typically done in low-power, high-latency configurations, whilst the Chinese ICT University want to go for high performance (without busting the building's water-cooling when you have 1,000 of the 16-processor chips in the same room) so they can get that number one slot for the world's fastest supercomputer.
the article has missed out some important information, which is that they are planning two versions of the CPU. the first is a Quad-Core 65nm, and the second is a 16-core 28nm, which will use the same amount of power (about 12-15 watts). hopefully they will also do a Single-Core 28nm which would be under 1 watt, because at 1ghz the SIMD units are so powerful they can do 1080p at 100 frames per second. really, this CPU design is a game-changer. i've been advocating their use for some time - http://lkcl.net/laptop.html
you are completely wrong. this processor has over 200 x86 emulation instructions, allowing it to run x86 code with only a 30% performance penalty, under qemu. it also has two 256-bit vector pipelines that provide SIMD floating-point operations so powerful that a single 1ghz core can do 1080p at over 100 frames a second. to claim that "it will never work" in the face of evidence that you simply haven't looked at is ridiculous. look up the specifications on the GS464V, please. also, you are not aware that the Chinese Government has purchased 25% of MIPS, and is working with the MIPS teams in the U.S. to create this processor. this processor *IS* MIPS's high-performance, low-power 64-bit MIPS chip.
whilst this is interesting, it is a statistical sample of one family and one family only, albeit a rather long sample. we do not, for example, "modify our sentence structure to repeat more frequently words when immediately learned", but we do find ourselves using words which we know that baby lilyana now knows, in order to more include her in our day-to-day lives: there's a subtle difference.
one clarification: the article seems to be pointing out that it is through speech that the child "trains" the adults (not the other way round), the possible mistaken implication being that it is exclusively by speech that children get their adults to adapt to them. in fact, children do a hell of a lot more than use words to get their adults to do their bidding!
as lilyana is 23 months, we will be leaving it another 6 months or so for her to basically do as she pleases, when she pleases, with us supporting her at every step, so that she gets a chance to see how the world works _without_ being made massively and irrevocably insecure or limited by "no" [except when it's dangerous!].
the main site also reports that you can either put up to 2mb of 2nd level cache down, to get high performance, or you can put zero cache down, to save power. the usual deal, basically.
"The LEON4 pipeline uses 64-bit internal load/store data paths, with an AMBA AHB interface of either 64- or 128-bit. Branch prediction, 1-cycle load latency and a 32x32 multiplier results in a performance of 1.7 DMIPS/MHz, or 2.1 CoreMark/MHz."
there's an excellent overview from 2009 of the LEON4 architecture, even if it's just the abstract of a paper, try googling this:
Next Generation Multi-Purpose Microprocessor
Abstract for Presentation at MPSA, 4th of November 2009
i did hear that ARM has a jazelle-like acceleration for CLR. it is not well-understood, and, crucially as you point out, there isn't much call for it because you can't run silverlight on a non-existent OS!:)
I've been trying to get an article through slashdot submission which describes exactly this: perhaps this article which has been accepted will trigger people to realise what i'm on about. if you put multiple RISC cores into 28nm or below, they SCREAM along at such unbelievably fast speeds that pure economics dictates that it is insane to ignore them. LEON4 by gaisler.com can do up to 8 cores, each at 1.5ghz, in 30nm. the size of the chip is so small that you can fit i believe it's around 10,000 processors onto a single 12in wafer. each wafer is $10k each, meaning that each IC is $1 each. add $1 for plastic packaging; add $1.50 for running test vectors at the plant, and you have a grand total of $3.50 for the manufacturing cost of each CPU, in mass-volume. of course, you have to amortise the NREs which are somewhere in the insane range of $5 million, but if you sell 5 million processors, that's only $1 per processor!
and so that's what... $5 or thereabouts... for an 8 core 1.5ghz processor, with 1.7DMIPS/Mhz performance (roughly the same as an ARM Cortex A9 or the MIPS 1074k). and, because it will be an "integrated" System-on-a-Chip, it will have on-board DDR2 or DDR3 RAM controller, HDMI, SATA-II, USB2, PCIe, Gigabit Ethernet - everything that is listed on the article presented by the OP - so you could have an unbelievably powerful Desktop or Server system, consuming only about 4 watts of power for the complete system, with 12ghz of processing power and 2gb of RAM costing only around $50 in parts.
so i have to ask - at what point does the economics become so blatantly in favour of RISC cores that people simply realise it is truly "Game Over" for Microsoft? what's it really going to take? do we _have_ to get down to 22nm or below, where 1.5ghz becomes 2.5 to 3ghz, and 10,000 cores becomes 20,000 cores on a single 12in wafer, and the price for 20ghz of processing power is $3 per CPU? really - what am i missing? i just don't get it.
he issue that you've got is that a) microsoft is not going to have windows for ARM until 2013, and even then it is impossible to get third party developers to do total rewrites of drivers b) emulation of x86, even with hardware assistance (similar to jazelle) only provides something like 30% equivalent performance. so you have a great processor, maybe 2ghz dual-core if you get the one from nufront, you smash its capabilities down to a staggering and mundane 700mhz, and you can only get up to about 1.5 gb of RAM because you need at least some memory for the Host OS.
now, yes you could instead use the ICT's "Godson" upcoming GS464V Quad-Core MIPS processor, which will have over 200+ hardware-accelerated assistance emulation instructions, but this CPU is designed to target the Chinese Government's desire to have the fastest supercomputer in the world - it would just also so happen to make a great Desktop / Server product, too, and the target power consumption is just a tad higher than any ARM processor.
overall, then, this is, very unfortunately, just pure wishful thinking on the part of every single taiwanese manufacturer. it's quite simple: to emulate another OS, the performance hit is so high that to compensate you might as well stick with the x86 processors, even if the higher performance ARM or MIPS processors were available they are actually significantly more expensive.
so instead, why not accept the fact that much much cheaper systems can be made, based around such low-power high-integrated embedded ARM and MIPS processors, and let the buyers decide?
http://lkcl.net/laptop.html - i am advocating a hardware design approach which would fulfil the criteria of being upgradeable as-and-when. using, for example, the recently-announced "Bloom Laptop" concept for the casework, and Embedded SoC CPUs for the hardware, as a modular design. this approach simply is not possible with Intel or AMD CPUs.
someone told me, 20 years ago, that if you design an idiot-proof OS, then only idiots will use it. in this case, this is a good thing, because their bugreports are kept away from debian...
a friend of mine worked for a vehicle manufacturer, on engine control management and calibration. he took a car out for a drive one day, and was asked to obtain the figures on the engine's highway performance. so he rigged up a dot-matrix printer (1980s...) to a laptop, which dutifully printed out the speed and fuel economy figures every few seconds.
whilst driving down the highway, with cars zooming past and honking him on either side due to his religious adherence to the posted speed limit of 55mph, a police officer, irate at having missed the speeding vehicles, picked on my friend and accused him of driving at 70mph.
in court, my friend simply provided the evidence of the printer and pleaded guilty to the lesser charge of driving at 55.5mph in a 55mph speed limit...
because it's royalty-free for implementations of VP8 algorithms when those algorithms are free software implementations. this is HIGHLY significant when it comes to cost-sensitive products. even the MPEG LA group has recognised the importance of automatic royalty-free patent grants, in their call for contributions to the upcoming MPEG-2 algorithm. you should read slashdot, you know;) or did you miss these stories last week, or did you not understand the significance?
i keep having to point this out to people, time and time again: broadcasting and DRM are mutually exclusively incompatible. Free Software people recognise this, and anyone who fails to recognise it is just plain dumb. or is being paid to pretend to be dumb. let's do a simple maths demo. go get your calculator, and hit the following buttons: type in 1, then hit "-". then type 1000, then hit 1/x, then hit equals. then hit "power (x/y)" and then 1000 again. press equals, and you should have 0.36769 or thereabouts. now do the same, substituting 10,000, then 100,000, then 1,000,000 and keep doing that until you reach the limit of the digits of your calculator.
the number displayed on your screen is 1/e (2.7818281828) which should mean something to you.
now do this: instead of 0.999999 to the power of 1000000, try even something like 0.9999998 to the power of 1000000. you should notice something VERY quickly: it's almost zero. now try 0.9999991 to the power of 1000000 - you should notice something even more startling: it's almost 1.
this demonstrates something very very simple: that it doesn't MATTER how complex the DRM is (0.0000001 or 0.00000001 probability of one person breaking it) - sheer weight of numbers of people around the world WILL break it, period. that really is the end of the matter. the sooner that people recognise and accept this, the sooner we can get on with something more constructive to do with our time, such as watching the next episode of Stargate on the device of OUR choice.
DRM can be effectively and easily implemented by XORing a Copyright Notice on top of the data. it's as good a measure as any, costs virtually nothing in terms of performance, does not interfere with distribution mechanisms (IP Multicast for example), can be "claimed" to be "encryption" under the DMCA, and makes it bluntly, bluntly clear that anyone dumb enough to remove it and spread the resultant file around the internet is DEFINITELY violating Copyright.
even as a free software developer (apart from the stupidity of the DMCA itself, which destroyed opportunities for me to make money from some of my skills and abilities), i see no reason why such a simple broadcastable scheme should not be more widely deployed.
Slashdot Mirror
when they were being measured, i believe the statistics were somewhere around 300+ per month. at over 3 years of development at the time, that would easily exceed 10,000 commits. if i had continued on the project, at that rate, the number of commits would be somewhere exceeding 70,000. rapid and proper incremental code development is like that.
l.
tesla turbines do not cause turbulence.
cash, which can be transferred from person to person, is untraceable and unstoppable. each person transfers cash by means of physically moving their arms, holding the cash in their hand, and dropping into the hand of the next person.
"i'll get youuu, disneyy, and your little talking mouse tooo AH hahahahahaaaa"
the list of functionality sounds like a perfect recipe for absolutely every major software company under the sun to begin anti-trust lawsuits, to me. oh, and patent infringement cases, too...
yes, that's absolutely correct - your conclusion is, however ("what a load of nonsense") completely wrong. to illustrate, you have to bear in mind that all modern CISC processors have, at their core, a RISC processor underneath. the "CISC" part simply provides an on-board translator from the complex to the reduced instruction set.
as to the rest, i'm not sure how to tell you that it doesn't matter if the processor does complex work, really slowly, or does simple work, really quickly: in the end, the results are still obtained, but in the "simple" case, you get the benefit of having far less silicon, and thus far less power used.
of much more serious concern - to google - is the fact that they are *knowingly* not pursuing GPL Copyright Infringement cases against Android-Linux GPL violators. if you fail to pursue a Copyright violation, it can be argued that you have "no interest" in protecting the Copyrighted material. as it is not in google's interests to pursue copyright violations because that would reduce the number of google android systems in the world, thus affecting their bottom line by reducing advertising income, they're in a bit of shit.
of much more serious concern - to google - is the fact that they are *knowingly* not pursuing GPL Copyright Infringement cases against Android-Linux GPL violators. if you fail to pursue a Copyright violation, it can be argued that you have "no interest" in protecting the Copyrighted material. as it is not in google's interests to pursue copyright violations because that would reduce the number of google android systems in the world, thus affecting their bottom line by reducing advertising income, they're in a bit of shit.
it's not that they're 32-bit or 64-bit that's so important, it's that until the Cortex A9, you couldn't use ECC RAM. also, with only 32-bit memory addressing, and with peripherals memory-mapped, many ARM SoCs simply can't do more than 1gb RAM (and many Cortex A9s can't do more than 2gb). then, also, there is the lack of virtualisation, which, again, has only been corrected in the Cortex A9 design.
"low power" quad-core 65nm 1ghz MIPS64 chips use 10 watts; 90nm, 20 watts. if you go to 28nm and stay at 1ghz, you divide by four - so that's 10/4 = 2.5 watts.
also, there are two different configurations for 65nm done by TSMC: one is high-performance (lower cost, 20 masks) and the other is lower-power (slightly higher cost, 32 masks). the lower-power CMOS one was only invented recently, so this is why you often see e.g. Broadcom Network / Server MIPS64 Quad-Core 1ghz 65nm CPUs consuming 10-20 watts. with the mask charges (NREs) being measured in $millions and the verification as well it's not justifiable financially to do a conversion of these older ICs to the newer lower-power fab process.
so there are a lot of factors that need to be taken into consideration. also you have to bear in mind that speed is a trade-off against latency. ARM SoCs are typically done in low-power, high-latency configurations, whilst the Chinese ICT University want to go for high performance (without busting the building's water-cooling when you have 1,000 of the 16-processor chips in the same room) so they can get that number one slot for the world's fastest supercomputer.
the article has missed out some important information, which is that they are planning two versions of the CPU. the first is a Quad-Core 65nm, and the second is a 16-core 28nm, which will use the same amount of power (about 12-15 watts). hopefully they will also do a Single-Core 28nm which would be under 1 watt, because at 1ghz the SIMD units are so powerful they can do 1080p at 100 frames per second. really, this CPU design is a game-changer. i've been advocating their use for some time - http://lkcl.net/laptop.html
you are completely wrong. this processor has over 200 x86 emulation instructions, allowing it to run x86 code with only a 30% performance penalty, under qemu. it also has two 256-bit vector pipelines that provide SIMD floating-point operations so powerful that a single 1ghz core can do 1080p at over 100 frames a second. to claim that "it will never work" in the face of evidence that you simply haven't looked at is ridiculous. look up the specifications on the GS464V, please. also, you are not aware that the Chinese Government has purchased 25% of MIPS, and is working with the MIPS teams in the U.S. to create this processor. this processor *IS* MIPS's high-performance, low-power 64-bit MIPS chip.
is that the same as minesweeper? :)
whilst this is interesting, it is a statistical sample of one family and one family only, albeit a rather long sample. we do not, for example, "modify our sentence structure to repeat more frequently words when immediately learned", but we do find ourselves using words which we know that baby lilyana now knows, in order to more include her in our day-to-day lives: there's a subtle difference.
one clarification: the article seems to be pointing out that it is through speech that the child "trains" the adults (not the other way round), the possible mistaken implication being that it is exclusively by speech that children get their adults to adapt to them. in fact, children do a hell of a lot more than use words to get their adults to do their bidding!
as lilyana is 23 months, we will be leaving it another 6 months or so for her to basically do as she pleases, when she pleases, with us supporting her at every step, so that she gets a chance to see how the world works _without_ being made massively and irrevocably insecure or limited by "no" [except when it's dangerous!].
the main site also reports that you can either put up to 2mb of 2nd level cache down, to get high performance, or you can put zero cache down, to save power. the usual deal, basically.
http://www.gaisler.com/cms/index.php?option=com_content&task=view&id=338&Itemid=231
"The LEON4 pipeline uses 64-bit internal load/store data paths, with an AMBA AHB interface of either 64- or 128-bit. Branch prediction, 1-cycle load latency and a 32x32 multiplier results in a performance of 1.7 DMIPS/MHz, or 2.1 CoreMark/MHz."
there's an excellent overview from 2009 of the LEON4 architecture, even if it's just the abstract of a paper, try googling this:
Next Generation Multi-Purpose Microprocessor
Abstract for Presentation at MPSA, 4th of November 2009
hope that helps.
i did hear that ARM has a jazelle-like acceleration for CLR. it is not well-understood, and, crucially as you point out, there isn't much call for it because you can't run silverlight on a non-existent OS! :)
I've been trying to get an article through slashdot submission which describes exactly this: perhaps this article which has been accepted will trigger people to realise what i'm on about. if you put multiple RISC cores into 28nm or below, they SCREAM along at such unbelievably fast speeds that pure economics dictates that it is insane to ignore them. LEON4 by gaisler.com can do up to 8 cores, each at 1.5ghz, in 30nm. the size of the chip is so small that you can fit i believe it's around 10,000 processors onto a single 12in wafer. each wafer is $10k each, meaning that each IC is $1 each. add $1 for plastic packaging; add $1.50 for running test vectors at the plant, and you have a grand total of $3.50 for the manufacturing cost of each CPU, in mass-volume. of course, you have to amortise the NREs which are somewhere in the insane range of $5 million, but if you sell 5 million processors, that's only $1 per processor!
and so that's what... $5 or thereabouts... for an 8 core 1.5ghz processor, with 1.7DMIPS/Mhz performance (roughly the same as an ARM Cortex A9 or the MIPS 1074k). and, because it will be an "integrated" System-on-a-Chip, it will have on-board DDR2 or DDR3 RAM controller, HDMI, SATA-II, USB2, PCIe, Gigabit Ethernet - everything that is listed on the article presented by the OP - so you could have an unbelievably powerful Desktop or Server system, consuming only about 4 watts of power for the complete system, with 12ghz of processing power and 2gb of RAM costing only around $50 in parts.
so i have to ask - at what point does the economics become so blatantly in favour of RISC cores that people simply realise it is truly "Game Over" for Microsoft? what's it really going to take? do we _have_ to get down to 22nm or below, where 1.5ghz becomes 2.5 to 3ghz, and 10,000 cores becomes 20,000 cores on a single 12in wafer, and the price for 20ghz of processing power is $3 per CPU? really - what am i missing? i just don't get it.
he issue that you've got is that a) microsoft is not going to have windows for ARM until 2013, and even then it is impossible to get third party developers to do total rewrites of drivers b) emulation of x86, even with hardware assistance (similar to jazelle) only provides something like 30% equivalent performance. so you have a great processor, maybe 2ghz dual-core if you get the one from nufront, you smash its capabilities down to a staggering and mundane 700mhz, and you can only get up to about 1.5 gb of RAM because you need at least some memory for the Host OS.
now, yes you could instead use the ICT's "Godson" upcoming GS464V Quad-Core MIPS processor, which will have over 200+ hardware-accelerated assistance emulation instructions, but this CPU is designed to target the Chinese Government's desire to have the fastest supercomputer in the world - it would just also so happen to make a great Desktop / Server product, too, and the target power consumption is just a tad higher than any ARM processor.
overall, then, this is, very unfortunately, just pure wishful thinking on the part of every single taiwanese manufacturer. it's quite simple: to emulate another OS, the performance hit is so high that to compensate you might as well stick with the x86 processors, even if the higher performance ARM or MIPS processors were available they are actually significantly more expensive.
so instead, why not accept the fact that much much cheaper systems can be made, based around such low-power high-integrated embedded ARM and MIPS processors, and let the buyers decide?
http://lkcl.net/laptop.html
http://lkcl.net/laptop.html - i am advocating a hardware design approach which would fulfil the criteria of being upgradeable as-and-when. using, for example, the recently-announced "Bloom Laptop" concept for the casework, and Embedded SoC CPUs for the hardware, as a modular design. this approach simply is not possible with Intel or AMD CPUs.
someone told me, 20 years ago, that if you design an idiot-proof OS, then only idiots will use it. in this case, this is a good thing, because their bugreports are kept away from debian...
a friend of mine worked for a vehicle manufacturer, on engine control management and calibration. he took a car out for a drive one day, and was asked to obtain the figures on the engine's highway performance. so he rigged up a dot-matrix printer (1980s...) to a laptop, which dutifully printed out the speed and fuel economy figures every few seconds.
whilst driving down the highway, with cars zooming past and honking him on either side due to his religious adherence to the posted speed limit of 55mph, a police officer, irate at having missed the speeding vehicles, picked on my friend and accused him of driving at 70mph.
in court, my friend simply provided the evidence of the printer and pleaded guilty to the lesser charge of driving at 55.5mph in a 55mph speed limit...
because it's royalty-free for implementations of VP8 algorithms when those algorithms are free software implementations. this is HIGHLY significant when it comes to cost-sensitive products. even the MPEG LA group has recognised the importance of automatic royalty-free patent grants, in their call for contributions to the upcoming MPEG-2 algorithm. you should read slashdot, you know ;) or did you miss these stories last week, or did you not understand the significance?
i keep having to point this out to people, time and time again: broadcasting and DRM are mutually exclusively incompatible. Free Software people recognise this, and anyone who fails to recognise it is just plain dumb. or is being paid to pretend to be dumb. let's do a simple maths demo. go get your calculator, and hit the following buttons: type in 1, then hit "-". then type 1000, then hit 1/x, then hit equals. then hit "power (x/y)" and then 1000 again. press equals, and you should have 0.36769 or thereabouts. now do the same, substituting 10,000, then 100,000, then 1,000,000 and keep doing that until you reach the limit of the digits of your calculator.
the number displayed on your screen is 1/e (2.7818281828) which should mean something to you.
now do this: instead of 0.999999 to the power of 1000000, try even something like 0.9999998 to the power of 1000000. you should notice something VERY quickly: it's almost zero. now try 0.9999991 to the power of 1000000 - you should notice something even more startling: it's almost 1.
this demonstrates something very very simple: that it doesn't MATTER how complex the DRM is (0.0000001 or 0.00000001 probability of one person breaking it) - sheer weight of numbers of people around the world WILL break it, period. that really is the end of the matter. the sooner that people recognise and accept this, the sooner we can get on with something more constructive to do with our time, such as watching the next episode of Stargate on the device of OUR choice.
DRM can be effectively and easily implemented by XORing a Copyright Notice on top of the data. it's as good a measure as any, costs virtually nothing in terms of performance, does not interfere with distribution mechanisms (IP Multicast for example), can be "claimed" to be "encryption" under the DMCA, and makes it bluntly, bluntly clear that anyone dumb enough to remove it and spread the resultant file around the internet is DEFINITELY violating Copyright.
even as a free software developer (apart from the stupidity of the DMCA itself, which destroyed opportunities for me to make money from some of my skills and abilities), i see no reason why such a simple broadcastable scheme should not be more widely deployed.