You can measure the amount of ability to choose and answer your own questions though. Also, this all very idealistic nonsense- until 300 years ago, we lived basically in tribal community, and people yearn for that, no matter how futuristic they dress up.
Alot also loose the land they had, to the banks over time and become glorified landscape facility managers for the bank or for example a energy company.
The guy in that "My-little-farm"-book you've read, might never have smiled so happy, and it might never have been his "little-farm". I know a lot of people who wont accept this though. You got to be rich, living the good life out there- else, where to daydream-escape towards from a day in the city.
Assuming TTIP fails, how will the next contract to attack democracy be called?
QTIP?
UTIP?
COUP?
GRACE?
At least put some effort into naming.
To have your rights grind away so slowly and being coerced like a mule to even thread that mill that maims you..
Im for a law that forbids to discuss content-similar contracts that have been downvoted for at least 8 years.
the biggest virtue of a c-programmer is temporary forgetfulness.
forget for the moment, that all of the old-guard-tech foundations is basically a castle made of glued together jello filled rubber ducky's.
forget all the tricks needed to jump through that final hoop in assembly.
forget even those hopeful endeavors of the languagewiser that stood up, and then came back because performance is a bitch and there use cases to edgy.
forget all those library's that overpRomised, undereallocated and disspointered.
forget all the futile attempts to steer this boat, carried on the hands of the likes of you, towards some sail-able waters.
blissful unawareness settles in, while every "good c-programmer" near you starts to spit fire as soon as management declares a new megalomaniac project in C worthy the effort and thus starting.
forget that strange feeling of elated Shame of being the best to repair the most broken car in town.
Then, and only then, you will be a "good" C-Programmer, one that knows all the tricks of trade, while not getting wiser.
And that's the root of what's wrong about TTIP: the US doesn't like the way Europeans vote, and wants to put a stop to it. Business interests need to be protected against the evil democracy.
The real trouble is the inability of chips to identify what haskell could completely avoid, doing the same algorithm for the same input repeatedly.
Hashing over input skip and save output, that would be a optimization.
Also Tools that give Programmers a DataOrientated-VisualFeedback of the OO-Cluttercosts they impart on there work.
A flag that guarantees side effect freedom to a set of operations and suboperations, for the processor that would be great.
Worth noting that modern processors aren't just pipelined; each core is composed of multiple pipelined units operating in parallel. Using the Tomasulo algorithm and derivatives, modern processors can execute a ton of instructions before instructions that appear before them are able to complete. The biggest issue is a branch that depends on a slow operation, which forces you to throw out tons of work if you mispredict.
Could you define slow operations? I am trying to better imagine a CPU having to throw out work where it is basically trying to get from a cache-miss (failure) to cache-miss (failure) as fast as it can.
I think what wyager meant is that on a mispredicted branch you have a CPU pipeline already filled with data and partial results (scheduled loads, r/w register conflicts, etc.) Now that we're at close to 30 stages per instruction, flushing all those partial results because your `if` went in a different branch than usual can get costly. In practice, after a branch misprediction you'll have to wait at least [pipeline_stages] cycles until you see the next instruction run. But if the scheduled instruction was something complex that comes from SSE / AES-NI / etc., you may have to wait even longer.
The real thing we care about is "wasted processor cycles", as well as their source. We measure some sources (branch mispredictions, instruction cache thrashing etc.) and some potential sources (e.g. cache misses). What we lack is a metric how bad each instance is. Not every branch misprediction has the same cost. With cache misses the cost can be nearly zero or very high. It would be nice to be able to measure (or simulate or estimate) the real magnitude of each problem.
As long as we don't have that, cache misses are a useful metric on their own, as long as one is aware of its caveats. As most things, cache misses come in various shades of grey.
This discussion reminded me of a formula for calculating the average cost of a cache miss in this pretty cool paper ("An Analysis of the Effects of Miss Clustering
on the Cost of a Cache Miss").
Why not scrap the USAF instead?
It all breaks down into mission support and drones in the long run? So why not scrap the organization that warps the strategic decisions ? Give everything ground mission related to the army, break everything that is strategic, as in supply, and the useless ICBMs of the sky to the new drone Department.
