There are already a lot of projects to try to improve efficiency of ships, including things like high-altitude kites delivering torque directly to the impellers. The motivation isn't environmental (although that gives good PR), it's that oil is expensive and lowering costs increases profits. If you can reduce the amount of oil a ship of a particular size has to carry, then that provides more cargo space, which is even better.
The problem in both cases is the capital investment. Ships and planes are both very expensive and have long service lives to make up for it. If you come up with a more power efficient mobile phone CPU (for example), then five years later you've replaced most of the old models with the new. Boats and planes stay in service for 20-30 years (or more). No one is going to throw away an existing fleet for one that's 20-30% cheaper to operate. You need to focus on things that can be retrofitted to existing craft.
Airlines are relatively good in one regard: their margins are razor thin. For Boeing, one of their more recent refinements to a popular series gave 1% improvements in fuel economy. That was enough of an improvement to be worth putting in the advertising material. When your profit margin is 1-2%, a 1% reduction in costs can double your profit.
An official statement from the FBI isn't exactly the same as some anonymous blog.
The FBI, that well-known organisation with large amounts of experience and jurisdiction over international matters? The CIA and NSA earlier this year made it clear that they did not have the capacity to accurately attribute cyber attacks and that any US policy based on accurate response in this area would be a mistake, so it's good to know that the FBI is more competent than their fellow agencies in this regard.
If you compile with -ffast-math, then they often will be. The problem is that the hardware implementations tend to fall into two categories. They're either very fast, and sometimes correct, or they're correct and very slow. The correct ones are normally microcoded, and if you've ever looked at CPU microcode then you'll know that it's an even worse thing to try to write complex algorithms in than assembly. You can generally do a better job with a C implementation that the compiler then optimises. The fast ones are very fast, but don't handle corner cases correctly (often the instructions predate the IEEE standard), so they're great for games and suchlike but not so good for scientific computing. GPUs are the worst offenders, often implementing things like trig functions as small lookup tables, leading to a lot of approximation.
For those cases you probably want to be using the builtin, which supports vector operands of arbitrary sizes. On some CPUs, it will generate a single instruction, for others it will do the extract and call the scalar version multiple times. A lot of the functions in math.h have data-dependent flow control, so probably aren't that amenable to vectorisation.
I don't know what the situation is like in GNU land, but in FreeBSD libc, we basically have two guys who care about libm (the library that implements the math.h stuff). One is a retired mathematics professor, I'm not sure what the background of the other is. There are a few other people who occasionally contribute to it, but no one else really wants to change it because floating point code is really hard to understand. You need to find someone who:
Is obsessive compulsive and likes optimising code.
Has a really strong background in this kind of numerical algorithms.
Has the patience to write and run correctness tests for corner cases as well as performance benchmarks.
Has free time.
This combination is pretty rare (if you think it describes you, the freebsd-numerics list would love you hear from you!).
Back when I was doing my PhD, the prevailing instruction to undergraduates was to favour iteration over recursion because it's faster. One of my colleagues rewrote some code to a single loop rather than recursive calls and found that on Linux it got slower, on Windows it stayed the same. Looking at the assembly, it turned out that managing his own stack on the stack generated significantly worse code with GCC than just using the call stack. On Windows, it was even more interesting: the Microsoft compiler was able to recognise the stack pattern and turn it into a recursive function, so his rewrite ended up generating the same code.
On the stack size issue, it's true that this can be a problem in embedded contexts. For a randomised quicksort implementation, the stack depth needed should be O(log(n)), so unless you're sorting insanely large things it shouldn't be an issue. The default stack size for FreeBSD is 1MB * sizeof(void*), so there's a fair bit of space.
The first is that you need to keep testing. The next version of the C compiler may generate better code than your assembly. Or the version after. Optimisers keep improving (hopefully - occasionally they get worse, but if you want to avoid that then contribute test cases to the performance regression suite), but your assembly won't.
The second is that performance for this kind of code can be highly microarchitecture dependent. One of the FreeBSD devs did some analysis of a variety of different SSE / AVX techniques for speeding up things like memset / memcpy. It turns out that across the last two generations of Intel chips you get very different performance for the different instruction combinations and there's no clear winner that's better on all. For Centaur chips, the best thing apparently is to have a simple byte copy loop aligned to fit into a fetch granule and the microcode will recognise the idiom and do a cache-line-at-a-time copy...
If what you write were true, it would have happened a very long time ago.
But it didn't. Why?
It did, but only among the people who actually needed to speak to foreigners. Go back a couple of hundred years and most people never move more than 20 miles from the place they were born. Single languages within countries were not that common - French only became the universal language in France a couple of hundred years ago. Meanwhile, most of the nobility in Europe would learn French growing up so that they could travel and talk to other members of the nobility, irrespective of where they were from. When common people started travelling, they vastly outnumbered the aristos, so didn't really care what their conventions were and gradually moved towards treating English in the same way.
The key point about English is that, while it's not the easiest language to learn to speak well, it is one of the easiest to learn to speak badly but comprehensibly. People can speak English really badly and still make themselves understood. This gives it a nice incremental learning curve where the result of a small bit of effort is worthwhile.
Per tab security so visiting myonlinebank.com and evilmalwaresite.com at the same time won't be a problem sure, but honestly I don't care if one image can bork just that image or the whole webpage since they from my perspective is equally untrusted.
You don't use webmail then? Or any web pages that have adverts in them?
Exactly. The problem with OpenSSL was that everyone used it, no one looked inside it. Those of us who did look inside it recoiled in horror and didn't do proper code review because 'kill it with fire' was the immediate reaction for anyone looking at the code. Open source isn't magic. People who build their business on a third party library have a lot of choice in terms of who provides the support (bug fixing, code auditing, and so on) for that library. Far more than with a proprietary library, where you're locked into a single source. If everyone choses to get support for the product using the power of wishful thinking, then don't be surprised if the code is crap.
It depends a bit on your definition of a library. In the broadest sense, it's just a body of code that other things use. Programs that communicate via pipes fall into this category as do language interpreters. Bash definitely meets this definition. There's more to libraries than just linker input.
You talked about energy, not about pollutants or environmental costs. The wholesale price is at least the cost of manufacture including the cost of the energy used to produce the panels. If I can buy a panel and get out of it energy worth more than I paid for the panel, then someone else must have been to make the panel for a lower monetary cost than the cost of the panel (or they wouldn't have sold it to me at that price) and, because energy is fungible, their energy cost must have been lower than the energy produced.
It takes more energy to produce a solar panel than it produces in its lifetime of use
This isn't just bullshit, it's obvious bullshit. Buying panels at consumer prices has a measurable RoI, which is 3-10 years depending on various conditions (and most of the cost for consumer installations is the labour cost of the installation). Buying them at wholesale prices has a much shorter RoI. If they cost more energy to produce than they generate then even with manufacturing and raw material costs of zero then this wouldn't be possible.
Really? How do you use it? I saw some comments that required pretending that your CardDAV server was a Google account and then fudging things, but couldn't get them to work.
First, that's with a single thread and a single security context. If each one is an isolated sandbox it's not the case (trust me on this: it's my research area and we've done a lot of benchmarking). Second, even if it were true, it would be a lot less power efficient. If you can parallelise your workload, then two 1.5GHz cores will use less power than one 3GHz one. Four 750MHz cores will use less still.
Until a few years ago, most computers had a single core, so there wasn't much point trying to exploit parallelism and the fastest way of implementing many problems was to serialise them. That's no longer an automatic win.
European Jewish communities had lower infection rates for Black Death, Bubonic Plague, etc. Back then, society knew nothing about bacteria, viruses, or sanitation. Jews followed their religious laws regard washing of dishes before meals, and washing their hands before meals.
And this is another example of evolution, albeit of the memetic rather than genetic variety. If you start with a bunch of crazy religions prohibiting random things then after a few generations the ones that prohibited things that were dangerous are going to be more likely to survive than the ones that prohibited things that were beneficial. The prohibition against pork and shellfish in Judaism is another good example. Pigs are sufficiently similar to humans that it's relatively easy for diseases to cross the species barrier, shellfish are very likely to cause illness if not properly stored and prepared. The societies that refuse to eat them are more likely to flourish, particularly in areas of the world where the climate is hot and water is relatively scarce.
How common are microSD cards these days? My current Android phone doesn't have one and it seems that both microSD cards and removable batteries are far more rare than they used to be.
My girlfriend's Windows phone is the first mobile device I've used with a UI that wasn't complete crap. If it weren't for the fact that it completely lacks all of the functionality that I want from a mobile device (decent OSM client, CalDAV / CardDAV sync [which Android doesn't have by default either - so much for Google and open standards], MPD client that doesn't completely suck, ownCloud client) then I'd be quite tempted.
Samsung doesn't have this issue because they consume most of the space with bloatware crap before you buy the device. If that's a problem, then you can return it to the shop as soon as you discover it (or just not buy it, if you've done your research properly before hand). This is different from the Apple case, where the extra space was consumed after purchase.
My first Android phone was an HTC Desire, which had 512MB of flash. The OS was on a separate partition to the user-accessible space, so it only allowed 100MB for apps that I installed. A big chunk of the 400MB or so was filled up with crap like Facebook and Twitter apps that I never used, and with things like the Android Browser that had to be upgraded because of security holes and ended up with the real copy in the 100MB. They put so much crap in the default image that they couldn't figure out how to squeeze 2.3 onto the device.
They're likely to be bursty and when you get the data you want to run most of them in parallel. Add to that, current constraints on CPU design (Dennard Scaling no longer working) mean that adding a load of cores that spend most of their time sleeping is actually quite an easy thing to do.
Slashdot Mirror
There are already a lot of projects to try to improve efficiency of ships, including things like high-altitude kites delivering torque directly to the impellers. The motivation isn't environmental (although that gives good PR), it's that oil is expensive and lowering costs increases profits. If you can reduce the amount of oil a ship of a particular size has to carry, then that provides more cargo space, which is even better.
The problem in both cases is the capital investment. Ships and planes are both very expensive and have long service lives to make up for it. If you come up with a more power efficient mobile phone CPU (for example), then five years later you've replaced most of the old models with the new. Boats and planes stay in service for 20-30 years (or more). No one is going to throw away an existing fleet for one that's 20-30% cheaper to operate. You need to focus on things that can be retrofitted to existing craft.
Airlines are relatively good in one regard: their margins are razor thin. For Boeing, one of their more recent refinements to a popular series gave 1% improvements in fuel economy. That was enough of an improvement to be worth putting in the advertising material. When your profit margin is 1-2%, a 1% reduction in costs can double your profit.
An official statement from the FBI isn't exactly the same as some anonymous blog.
The FBI, that well-known organisation with large amounts of experience and jurisdiction over international matters? The CIA and NSA earlier this year made it clear that they did not have the capacity to accurately attribute cyber attacks and that any US policy based on accurate response in this area would be a mistake, so it's good to know that the FBI is more competent than their fellow agencies in this regard.
If you compile with -ffast-math, then they often will be. The problem is that the hardware implementations tend to fall into two categories. They're either very fast, and sometimes correct, or they're correct and very slow. The correct ones are normally microcoded, and if you've ever looked at CPU microcode then you'll know that it's an even worse thing to try to write complex algorithms in than assembly. You can generally do a better job with a C implementation that the compiler then optimises. The fast ones are very fast, but don't handle corner cases correctly (often the instructions predate the IEEE standard), so they're great for games and suchlike but not so good for scientific computing. GPUs are the worst offenders, often implementing things like trig functions as small lookup tables, leading to a lot of approximation.
For those cases you probably want to be using the builtin, which supports vector operands of arbitrary sizes. On some CPUs, it will generate a single instruction, for others it will do the extract and call the scalar version multiple times. A lot of the functions in math.h have data-dependent flow control, so probably aren't that amenable to vectorisation.
I don't know what the situation is like in GNU land, but in FreeBSD libc, we basically have two guys who care about libm (the library that implements the math.h stuff). One is a retired mathematics professor, I'm not sure what the background of the other is. There are a few other people who occasionally contribute to it, but no one else really wants to change it because floating point code is really hard to understand. You need to find someone who:
This combination is pretty rare (if you think it describes you, the freebsd-numerics list would love you hear from you!).
Back when I was doing my PhD, the prevailing instruction to undergraduates was to favour iteration over recursion because it's faster. One of my colleagues rewrote some code to a single loop rather than recursive calls and found that on Linux it got slower, on Windows it stayed the same. Looking at the assembly, it turned out that managing his own stack on the stack generated significantly worse code with GCC than just using the call stack. On Windows, it was even more interesting: the Microsoft compiler was able to recognise the stack pattern and turn it into a recursive function, so his rewrite ended up generating the same code.
On the stack size issue, it's true that this can be a problem in embedded contexts. For a randomised quicksort implementation, the stack depth needed should be O(log(n)), so unless you're sorting insanely large things it shouldn't be an issue. The default stack size for FreeBSD is 1MB * sizeof(void*), so there's a fair bit of space.
The first is that you need to keep testing. The next version of the C compiler may generate better code than your assembly. Or the version after. Optimisers keep improving (hopefully - occasionally they get worse, but if you want to avoid that then contribute test cases to the performance regression suite), but your assembly won't.
The second is that performance for this kind of code can be highly microarchitecture dependent. One of the FreeBSD devs did some analysis of a variety of different SSE / AVX techniques for speeding up things like memset / memcpy. It turns out that across the last two generations of Intel chips you get very different performance for the different instruction combinations and there's no clear winner that's better on all. For Centaur chips, the best thing apparently is to have a simple byte copy loop aligned to fit into a fetch granule and the microcode will recognise the idiom and do a cache-line-at-a-time copy...
File a bug report for the compiler with 'missed optimization opportunity' in the title and a reduced test case.
We like to see real-world examples of where we're generating bad code - if we don't see them, we can't fix them.
If what you write were true, it would have happened a very long time ago. But it didn't. Why?
It did, but only among the people who actually needed to speak to foreigners. Go back a couple of hundred years and most people never move more than 20 miles from the place they were born. Single languages within countries were not that common - French only became the universal language in France a couple of hundred years ago. Meanwhile, most of the nobility in Europe would learn French growing up so that they could travel and talk to other members of the nobility, irrespective of where they were from. When common people started travelling, they vastly outnumbered the aristos, so didn't really care what their conventions were and gradually moved towards treating English in the same way.
The key point about English is that, while it's not the easiest language to learn to speak well, it is one of the easiest to learn to speak badly but comprehensibly. People can speak English really badly and still make themselves understood. This gives it a nice incremental learning curve where the result of a small bit of effort is worthwhile.
Or, as we call the language made from a mish mash of existing languages today: English.
Per tab security so visiting myonlinebank.com and evilmalwaresite.com at the same time won't be a problem sure, but honestly I don't care if one image can bork just that image or the whole webpage since they from my perspective is equally untrusted.
You don't use webmail then? Or any web pages that have adverts in them?
Exactly. The problem with OpenSSL was that everyone used it, no one looked inside it. Those of us who did look inside it recoiled in horror and didn't do proper code review because 'kill it with fire' was the immediate reaction for anyone looking at the code. Open source isn't magic. People who build their business on a third party library have a lot of choice in terms of who provides the support (bug fixing, code auditing, and so on) for that library. Far more than with a proprietary library, where you're locked into a single source. If everyone choses to get support for the product using the power of wishful thinking, then don't be surprised if the code is crap.
It depends a bit on your definition of a library. In the broadest sense, it's just a body of code that other things use. Programs that communicate via pipes fall into this category as do language interpreters. Bash definitely meets this definition. There's more to libraries than just linker input.
You talked about energy, not about pollutants or environmental costs. The wholesale price is at least the cost of manufacture including the cost of the energy used to produce the panels. If I can buy a panel and get out of it energy worth more than I paid for the panel, then someone else must have been to make the panel for a lower monetary cost than the cost of the panel (or they wouldn't have sold it to me at that price) and, because energy is fungible, their energy cost must have been lower than the energy produced.
It takes more energy to produce a solar panel than it produces in its lifetime of use
This isn't just bullshit, it's obvious bullshit. Buying panels at consumer prices has a measurable RoI, which is 3-10 years depending on various conditions (and most of the cost for consumer installations is the labour cost of the installation). Buying them at wholesale prices has a much shorter RoI. If they cost more energy to produce than they generate then even with manufacturing and raw material costs of zero then this wouldn't be possible.
Given that 1659 predates both Centigrade and Fahrenheit scales, what were the units that they used to record the temperature back then?
Really? How do you use it? I saw some comments that required pretending that your CardDAV server was a Google account and then fudging things, but couldn't get them to work.
First, that's with a single thread and a single security context. If each one is an isolated sandbox it's not the case (trust me on this: it's my research area and we've done a lot of benchmarking). Second, even if it were true, it would be a lot less power efficient. If you can parallelise your workload, then two 1.5GHz cores will use less power than one 3GHz one. Four 750MHz cores will use less still.
Until a few years ago, most computers had a single core, so there wasn't much point trying to exploit parallelism and the fastest way of implementing many problems was to serialise them. That's no longer an automatic win.
European Jewish communities had lower infection rates for Black Death, Bubonic Plague, etc. Back then, society knew nothing about bacteria, viruses, or sanitation. Jews followed their religious laws regard washing of dishes before meals, and washing their hands before meals.
And this is another example of evolution, albeit of the memetic rather than genetic variety. If you start with a bunch of crazy religions prohibiting random things then after a few generations the ones that prohibited things that were dangerous are going to be more likely to survive than the ones that prohibited things that were beneficial. The prohibition against pork and shellfish in Judaism is another good example. Pigs are sufficiently similar to humans that it's relatively easy for diseases to cross the species barrier, shellfish are very likely to cause illness if not properly stored and prepared. The societies that refuse to eat them are more likely to flourish, particularly in areas of the world where the climate is hot and water is relatively scarce.
Apple leaves out a VERY common feature
How common are microSD cards these days? My current Android phone doesn't have one and it seems that both microSD cards and removable batteries are far more rare than they used to be.
My girlfriend's Windows phone is the first mobile device I've used with a UI that wasn't complete crap. If it weren't for the fact that it completely lacks all of the functionality that I want from a mobile device (decent OSM client, CalDAV / CardDAV sync [which Android doesn't have by default either - so much for Google and open standards], MPD client that doesn't completely suck, ownCloud client) then I'd be quite tempted.
Samsung doesn't have this issue because they consume most of the space with bloatware crap before you buy the device. If that's a problem, then you can return it to the shop as soon as you discover it (or just not buy it, if you've done your research properly before hand). This is different from the Apple case, where the extra space was consumed after purchase.
My first Android phone was an HTC Desire, which had 512MB of flash. The OS was on a separate partition to the user-accessible space, so it only allowed 100MB for apps that I installed. A big chunk of the 400MB or so was filled up with crap like Facebook and Twitter apps that I never used, and with things like the Android Browser that had to be upgraded because of security holes and ended up with the real copy in the 100MB. They put so much crap in the default image that they couldn't figure out how to squeeze 2.3 onto the device.
They're likely to be bursty and when you get the data you want to run most of them in parallel. Add to that, current constraints on CPU design (Dennard Scaling no longer working) mean that adding a load of cores that spend most of their time sleeping is actually quite an easy thing to do.
Good thing laptops and WiFi work in bed.