This isn't the first time I've heard of reversible computing and its purported benefits, and over the years every time I looked it up I haven't seen significant advancements or implementations. This article is no exception. And I'm still not convinced there exists any design of a reversible-logic processor is practical or useful for general purpose computing, assuming that the physical hardware problems have been solved.
I would be quite happy to see a software simulation of an 8 bit processor with a simple instruction set and a small amount of RAM, all implemented in simulated reversible-logic gates. Does anyone know if such a simulation exists? Or is the answer "well, it's complicated" which means probably not?
>This is the dumbest research I've seen in 2015. There was actually no computation involved -- they just wanted to write a long string to disk. They concluded that adding the superfluous step of concatenating strings in memory, then writing to disk, was slower. Well duh! That's not what memory is for!
Agreed with you on the uselessness of their research, but that is most definitely one important and common use of memory: buffer caches used by the operating system.
Effectively, they unintentionally tested the speed of the OS to concatenate strings vs Java or Python. The researchers are wrong right out of the gate: they say "Heavy Disk Usage" in their research headline, but at no point did they actually test disk performance, everything they did is being handled by the OS buffer cache.
All the researchers have shown is that string concatenation operations in Java and Python are atrociously slow. The java example used the naive form a=a+b; to concatenate strings, which is one of the slowest ways to do it in Java if you are doing repeated concatenations to a string.
If, in their tests, they had also done a string concatenation in C by allocating a buffer and appending to it using a pointer (not strcat) the speed difference doing that vs. 1 million write calls would have been negligible.
Also, if they sync'd after each of a million 1-byte writes to test how slow "Heavy Disk Usage" is compared to a single write of a million bytes, they wouldn't have bothered finishing this paper at all because it's so damn obvious that memory is faster.
>The question is, what have we learned as an industry since 1982?
Quite a bit. I have three books on electromagnetic compatibility. The most recent, Electromagnetic Compatibility Engineering (2009), is comprehensive and thick enough to stun an ox.
What next? You use 15 or 20 character passwords, or a passphrase of several words.
But for the server side, use key strengthening with something like bcrypt or scrypt. If it takes 1 second on very fast hardware to hash a single password, then your attacker has to also spend a lot of time on each hash attempt. scrypt was also designed with custom hardware attacks in mind (it uses lots of memory) so it is still slow and expensive even if the attacker has key derivation logic in an asic or fpga.
If it takes a tenth of a second for an attacker to derive a key (or hash) from a password then a 10 character password is still incredibly strong. If the passwords have salt (as they should) even a plain english dictionary attack on a 2M password file will take years to finish.
As faster hardware becomes available, you adapt by changing the key derivation parameters.
I did something similar around the same year. I made a string of many (56 if I remember correctly) blue LEDs, each individually addressable and PWM dimmable, multiplexed thru an ethernet cable + 1 extra wire, all running off one atmega8 and a handful of 2n3906 / 2n3904s. No PC interface though, just had little programs written for the microcontroller.
I can't remember what software it was, but it included samples labeled "8-bit" and "16-bit" to demonstrate the difference between 8 and 16 bits/sample audio. I assumed the 8-bit audio file was deliberately made noisy and grainy, because it sounded much worse than the 16 bit file downsampled to 8.
>RSA for example needs two prime numbers as a keypair, so while the key length might be 512 bit, there are actually not that many from those 2^512 numbers to choose from. Also, certain key values are prone to attacks.
How many is not that many? Bruce Schneier in Cryptography Engineering calculates that 1 in 1386 numbers in the 2^2000 bit range is prime. In the 2^512 range primes are even more frequent, according to prime counting estimates.
It would get very tiresome for everyone to have to explain from axioms and first principles every opinion they held, even if they did reflect upon and study them. Alternately, do you think people who agree with you on whatever subject have also been "culturally informed" that way?
I am, of course, not talking about capitalism, communism, chalk, or cottonballs, but wearing socks with sandals.
If my math is right, Planck's length as your resolution limit gives you 6.187x10^34 possible marking positions per meter of stick, which means you can encode about 115 bits with one mark on a 1m Planck-grade stick.
I like the technological aspect of networked sensors and remote management, I intend to put sensors in my own home, but I can't get over how annoying this article is.
An article full of hand-waving is topped with this: "And this is what Urban OS is providing, this kind of solution to analyse mass data, enter it in a context and perform magical actions."
The cutesy use of computing terms is grating: "To support the myriad of different devices in a city the firm has developed an extensive set of application services that will run Urban OS, dubbed PlaceApps - the urban environment equivalent of apps on a smartphone."
"The OS completely bypasses humans to manage communication between sensors and devices such as traffic lights, air conditioning or water pumps that influence the quality of city life." What previous problem is solved by having the city "OS" manage my air conditioning? Do I use too much? Should I put sensors in my house so UrbanOS can tell if nobody's home, then shut it off for me?
Frankly I'm not comfortable with the degree of centralization implied in this article. The folks who run infrastructure already have or are installing ever more networked sensors to ease maintenance, administration, and lower maintenance costs.
I get the feeling the article writer and McLaren Electronic Systems have very different things in mind.
I don't care that it's Microsoft. I would feel exactly same way if the writer said the same about anything else. I have never developed using the.NET platform, so I'm not about to defend a position I don't hold regarding.NET superiority or inferiority.
> A man states his opinion and is immediately vilified. Yes, there is the danger that when one speaks his opinion someone else will express theirs in kind.
Slashdot Mirror
This isn't the first time I've heard of reversible computing and its purported benefits, and over the years every time I looked it up I haven't seen significant advancements or implementations. This article is no exception. And I'm still not convinced there exists any design of a reversible-logic processor is practical or useful for general purpose computing, assuming that the physical hardware problems have been solved.
I would be quite happy to see a software simulation of an 8 bit processor with a simple instruction set and a small amount of RAM, all implemented in simulated reversible-logic gates. Does anyone know if such a simulation exists? Or is the answer "well, it's complicated" which means probably not?
>According TFA, they actually do an explicit sync to disk at the end of the writes. So it's not purely writing into cache.
The code in the paper says they flush before closing the file. This is not the same as a sync. They don't even flush (or sync) after each write.
>This is the dumbest research I've seen in 2015. There was actually no computation involved -- they just wanted to write a long string to disk. They concluded that adding the superfluous step of concatenating strings in memory, then writing to disk, was slower. Well duh! That's not what memory is for!
Agreed with you on the uselessness of their research, but that is most definitely one important and common use of memory: buffer caches used by the operating system.
Effectively, they unintentionally tested the speed of the OS to concatenate strings vs Java or Python. The researchers are wrong right out of the gate: they say "Heavy Disk Usage" in their research headline, but at no point did they actually test disk performance, everything they did is being handled by the OS buffer cache.
All the researchers have shown is that string concatenation operations in Java and Python are atrociously slow. The java example used the naive form a=a+b; to concatenate strings, which is one of the slowest ways to do it in Java if you are doing repeated concatenations to a string.
If, in their tests, they had also done a string concatenation in C by allocating a buffer and appending to it using a pointer (not strcat) the speed difference doing that vs. 1 million write calls would have been negligible.
Also, if they sync'd after each of a million 1-byte writes to test how slow "Heavy Disk Usage" is compared to a single write of a million bytes, they wouldn't have bothered finishing this paper at all because it's so damn obvious that memory is faster.
>The question is, what have we learned as an industry since 1982?
Quite a bit.
I have three books on electromagnetic compatibility. The most recent, Electromagnetic Compatibility Engineering (2009), is comprehensive and thick enough to stun an ox.
What next? You use 15 or 20 character passwords, or a passphrase of several words.
But for the server side, use key strengthening with something like bcrypt or scrypt.
If it takes 1 second on very fast hardware to hash a single password, then your attacker has to also spend a lot of time on each hash attempt.
scrypt was also designed with custom hardware attacks in mind (it uses lots of memory) so it is still slow and expensive even if the attacker has key derivation logic in an asic or fpga.
If it takes a tenth of a second for an attacker to derive a key (or hash) from a password then a 10 character password is still incredibly strong.
If the passwords have salt (as they should) even a plain english dictionary attack on a 2M password file will take years to finish.
As faster hardware becomes available, you adapt by changing the key derivation parameters.
You are hilarious.
Submit?
Damn those benighted fools for having a preference that differs from yours!
Wasteland. The spiritual ancestor of the Fallout series.
Actually it must have been 36 LEDs now that I think about it.
I did something similar around the same year.
I made a string of many (56 if I remember correctly) blue LEDs, each individually addressable and PWM dimmable, multiplexed thru an ethernet cable + 1 extra wire, all running off one atmega8 and a handful of 2n3906 / 2n3904s.
No PC interface though, just had little programs written for the microcontroller.
1) Analog, used it just yesterday.
I can't remember what software it was, but it included samples labeled "8-bit" and "16-bit" to demonstrate the difference between 8 and 16 bits/sample audio.
I assumed the 8-bit audio file was deliberately made noisy and grainy, because it sounded much worse than the 16 bit file downsampled to 8.
Because Arduinos and plastic printers are enough for everyone.
See http://en.wikipedia.org/wiki/Absorption_refrigerator
Square the number of bits used in your asymmetric keys.
(Tongue in cheek.)
>RSA for example needs two prime numbers as a keypair, so while the key length might be 512 bit, there are actually not that many from those 2^512 numbers to choose from. Also, certain key values are prone to attacks.
How many is not that many? Bruce Schneier in Cryptography Engineering calculates that 1 in 1386 numbers in the 2^2000 bit range is prime. In the 2^512 range primes are even more frequent, according to prime counting estimates.
265? That's an odd number.
All the real nerds were doing circuits before Make and Arduino came along.
</beard>
It would get very tiresome for everyone to have to explain from axioms and first principles every opinion they held, even if they did reflect upon and study them.
Alternately, do you think people who agree with you on whatever subject have also been "culturally informed" that way?
I am, of course, not talking about capitalism, communism, chalk, or cottonballs, but wearing socks with sandals.
Just imagine: virtual hand-washing dishes, virtual weed pulling, virtual pebble sorting.
The video-game possibilities are endless!
> A 100MHz ARM core with enough flash and RAM on die to run a full operating system is about $1.
What operating system? What supplier and part number do you have in mind, exactly?
If my math is right, Planck's length as your resolution limit gives you 6.187x10^34 possible marking positions per meter of stick, which means you can encode about 115 bits with one mark on a 1m Planck-grade stick.
I like the technological aspect of networked sensors and remote management, I intend to put sensors in my own home, but I can't get over how annoying this article is.
An article full of hand-waving is topped with this:
"And this is what Urban OS is providing, this kind of solution to analyse mass data, enter it in a context and perform magical actions."
The cutesy use of computing terms is grating:
"To support the myriad of different devices in a city the firm has developed an extensive set of application services that will run Urban OS, dubbed PlaceApps - the urban environment equivalent of apps on a smartphone."
"The OS completely bypasses humans to manage communication between sensors and devices such as traffic lights, air conditioning or water pumps that influence the quality of city life."
What previous problem is solved by having the city "OS" manage my air conditioning? Do I use too much? Should I put sensors in my house so UrbanOS can tell if nobody's home, then shut it off for me?
Frankly I'm not comfortable with the degree of centralization implied in this article. The folks who run infrastructure already have or are installing ever more networked sensors to ease maintenance, administration, and lower maintenance costs.
I get the feeling the article writer and McLaren Electronic Systems have very different things in mind.
I don't care that it's Microsoft. I would feel exactly same way if the writer said the same about anything else. I have never developed using the .NET platform, so I'm not about to defend a position I don't hold regarding .NET superiority or inferiority.
> A man states his opinion and is immediately vilified.
Yes, there is the danger that when one speaks his opinion someone else will express theirs in kind.