The shell exec magic, especially when combined with notebook mode and pylab inline, can make some simple analyses of text data really dead simple. You can, for example, do something like:
Which will dump out a nice pretty 12-bin histogram of whatever the numeric data in the third column of output, of messages containing interesting_event was. To get this sort of fancy, run `ipython notebook --pylab=inline` and enjoy!
EDIT: for context, I wind up using this all the time to tease out information from Riak logs, like how long Bitcask merges take, in aggregate, and for locating particular events in time and characterizing their frequency.
Yes and yes! So, the C++ standard library differences don't usually bite you unless you're e.g. Building executables on windows with mingw and trying to link against libraries built with visual studio that use STL features at the API, but there are indeed several implementations out there. libstdc++, libc++, and msvcrt are among the more common.
As for other languages with several standard libraries: a while ago that was a frequent criticism of D -- there were two competing standard libraries, which caused some division in the community.
I think GP's point wasn't that their secrecy makes them deserve negative public opinion, rather that a policy of secrecy in general makes it rather difficult to believably deny allegations of questionable behavior -- that secrecy is a double-edged sword.
Also, I don't think it's entirely fair to construct a black-and-white dichotomy between government and private company. Companies working on government contracts are by definition somewhere between the two, so perhaps it's fair to demand transparency somewhere in between? I don't know where to draw those lines, I'm just trying to point out that there isn't, logically, much room for absolute arguments about private vs public on this particular topic.
There certainly is a very real cholera risk in the poorest communities in the US.
Take, for example, the colonias in southwestern Texas, where ~400k people live in informal housing without access to basic infrastructure or services, and where diseases like cholera and dengue fever have far higher rates of incidence. These aren't all illegal immigrants or anything, either -- the Texas secretary of state reports 64.4% of Texan colonias residents are US citizens[1].
It's easy to assume there's no poverty that deep in this country when, by and large, our standard of living is better than most of the world, but unfortunately there really are places in the US to which the descriptor "third world" is applicable.
I'm still learning my way around caches and memory timing, so if someone better educated than I could correct me if I'm wrong, I'd be very appreciative. That said, here's what I'd say:
The core of the issue is with cache-friendly access patterns. This is a simplified explanation, but here goes: CPUs only have so much cache, and the processor needs to keep enough data in that cache that it won't be left waiting for too long before the next batch of data requested from ram is available. To that end, when you access a chunk of memory, the CPU will grab the requested region and then some, hoping that most of your work for the next few microseconds will be within that region. The second implementation jumps by 1024 x sizeof(double) at each access (so, on my system that's 8k), which is plenty far to blow through whatever memory was prefetched with your access, and in so doing force the processor to sit around and wait for another memory location to be cached.
There's another, probably less significant way in which this is a pathological access pattern: alignment. When, in the first implementation, the processor operates on contiguous blocks of memory it is free to prefetch memory in nicely sized chunks that begin and end on convenient numbers, which is important because memory today is nothing if not a tower of multiplexed access -- asking for a few extra bits over the edge of a row, wherever those borders happen to be for your system (probably the width of the memory bus is a good guess), may not seem like much, but if it means the memory controller has to access a row of ram that it otherwise wouldn't, that involves first writing the data in the starting row, then waiting for the appropriate delay to save that data before switching rows and repeating the process. Looking at zeroarray2 in that context, you're asking the memory controller to save sizeof(double)*8 bits of zeroes, a fraction of a row, at once before moving on to another row only to revisit the first some time later.
Answers to the questions pertaining to memory (rather than concurrency) can all be found in Ulrich Drepper's excellent tour of contemporary memory systems, "What Every Programmer Should Know About Memory" ( http://www.akkadia.org/drepper/cpumemory.pdf ).
Which will dump out a nice pretty 12-bin histogram of whatever the numeric data in the third column of output, of messages containing interesting_event was. To get this sort of fancy, run `ipython notebook --pylab=inline` and enjoy!
EDIT: for context, I wind up using this all the time to tease out information from Riak logs, like how long Bitcask merges take, in aggregate, and for locating particular events in time and characterizing their frequency.