If your C is faster than your Assembly, that's because your Assembly is crap.
You are kidding yourself if you think you can write programs in assembler that run faster than the equivalent in C. Look at what my compiler generates for the C statement "return x/372;" with 64 bit ints on x64:
movslq %edi, %rax
imulq $738919105, %rax, %rax
movq %rax, %rcx
shrq $63, %rcx
sarq $38, %rax
addl %ecx, %eax
Your only practical approach as a human writing this in assembler is to use the slower 64 bit divide instruction. Puzzling out optimizations like this is a job much better suited for a the code generator in a compiler.
This is just one example among many arithmetic tricks of the trade. Register allocation and loop unrolling are two more low level optimizations that are no fun. At least not for me. I'd rather write the program in C, profile it, optimize my algorithms, and only then consider rewriting inner loops in assembler. Actually, I'd rather write the program in a proper modern programming language, and speed up its inner loops by rewriting them in C/assembler.
The paper assumes "that in the 100 m sprint he is able to develop a constant horizontal force F0 during the whole race", fits an air drag formula to laser measurements of an actual race, and concludes that Bolt expends 81.58kJ of mechanical work during a 100m sprint lasting 9.58 seconds. That may sound OK on the face of it, but 81.58kJ/9.58s is about 8500W (11.5HP) - more than four times the 2000W instantaneous maximum power output of elite track sprint cyclists. OK, maybe you believe in the overwhelming superiority of runners over cyclists. In that case, consider the drag of a body traveling at sprinting speeds. According to this bicycle power calculator, a non-aerodynamic rider might use as much as 500W at the maximum speed attained by Bolt. It is simply not possible that a runner's drag would be 17 times greater than an upright cyclist with knobby tires. This seems to prove that the paper's main assumption is wrong.
So what is going on? Well, we can see that there is an incredibly good fit between experimental data and the model. Clearly a combination of linear and quadratic force terms make the equation fit. However, the obvious answer is that these terms must primarily influence the force the sprinter is able to exert as a function of velocity. As I said, I'm not much of a runner, but I distinctly recall running out of leg speed when I used to attempt to sprint. Bolt's advantage seems to have more to do with muscle speed than raw power.
The failure to discuss this glaring discrepancy suggests the paper should not have been accepted for publication in its current form.
if they weren't grandfathered, the Nanny State would never approve them today.
There is hope: Not long ago Colorado approved 35mph neighborhood electric vehicles, conditional on a federal safety standard for such vehicles (and change in DOT reg to allow them on the roads).
I think that charging of batteries is mostly limited by the plug that it's connected to.
Charge time is often limited by battery chemistry and construction. Lithium ion batteries, for example, are typically limited to a rate of 1C (a theoretical 1 hour charge time from empty to 100%). In practice, those li-ion batteries take several hours to reach 100% charge because the rate slows down dramatically near as the battery reaches full.
Consider the Tesla S sedan: Not coincidentally, Tesla's 300A Supercharger stations "can charge about half the battery in 30 minutes." We are not likely to see faster charging options until new battery technology becomes available. Of course "the plug" (or more likely the socket in this case) substantially limits charging rate: Tesla's 1.4kW wall socket charger provides a mere 5 miles of range per hour of charge.
Secure voice is as easy as loading a ZRTP capable softphone (I use Jitsi) and registering on a SIP or XMPP network. Unencrypted connections to the PSTN are available from VOIP providers at reasonable prices.
If you want to run your own PBX, try Asterisk or FreeSwitch. You can set it up to connect to an ATA for use with a regular telephone.
It sounds like you prefer a DIY solution. If not, you might want to check out Phil Zimmerman's Silent Circle.
ZRTP looks solid to me. If the short authentication strings (SAS) check out, there is minimal likelihood of a successful attack on the protocol*. If you still don't trust it, jitsi can run peer to peer behind a vpn. If that's not good enough for you, you should be holding your conversations in a noisy location, away from all electronic devices, and out of sight of lip readers with telescopes.
*Jiti uses a 4 character SAS, which works out to around 24 bits for a 0.000006% chance of successful attack. Attack opportunities are strictly limited by the nature of the protocol (e.g. early commitment to an SAS; the use of cached secrets from previous conversations for authentication). Technically, this may not meet modern cryptographic standards for non-negligibility, but with a 0.999994% chance of an attack being made obvious, you will almost certainly know something is up and can take measures should it happen.
I wish Linux just worked.
My living room computer has problems with audio, video, application crashes, ACPI and update breaks because
(MadMaverick9: you completely missed the point. See the reply in my blog if you care, I'm not going to encourage a bad thread here.)
I called AppleCare as soon as the plug-in showed up as invalid. The two most infuriating aspects of the call were the impression I got that Apple could hack into my Mac at any time (assuming a network connection to Apple) and the claim that Apple had not installed Java on my machine in the first place. After the call, I checked and indeed Java was installed when I bought the computer, directly contradicting the support supervisor's assertion, but I still have no proof of whether or not Apple has the power to silently force updates.
The security implications of promiscuously running Java applets, so Apple was right to do something. The problem is that they did so without warning; without asking permission; and with no obvious way to re-enable the plug-in. I understand that some people successfully re-enable applets by modifying XProtect.meta.plist, but all I managed was to eliminate the "inactive plug-in" message, leaving a completely empty gray rectangle.
Now, with Apple having repaired the problem, I'm calming down, but I've set up a blog, AppleHackedMyMac to discuss this, the possibly encroaching walled garden, security, and the like.
On a downhill slope, if your legs get tired you will start to go faster, eventually to the point that the pedals are turning fast enough that you can no longer synchronize your leg strokes with the position of the pedals to control your speed at all. At that point the unicycle will get ahead of you and you will fall backwards onto your ass at high speed, which isn't much fun.
I agree that there is more risk riding down trails than up them, but not for the reason you cite. A rider has no angular momentum when the unicycle shoots forward, and does not "rotate backwards onto your ass" in this scenario. Instead, you put a foot down on the ground and, usually, walk/jog forward (thus the term unplanned dismount). There is a risk of tripping, especially on uneven terrain, but no one said mountain riding was safe.