If you are going to do that you need to ban chart trading and day trading as well and get back to people investing based on actual fundamentals. Good luck with that.

In the meantime the stock market is nothing but a game that has little to no relation to the success or viability of the businesses and in that world the fast trading algorithms serve to provide liquidity.

"Ever hear of a mutual fund, 401k, 403b, IRA, etc"

Ever hear of a bond, a commodity, a long term investor... When an auto-trade algorithm hits an action point... it has no impact on any of them. This only potentially impacts high risk investors and by definition they've opt'd in to the risk and have the burn coming.

Anyone else either isn't speculating by gambling in the stock market or is at least trading on longer scales of time that erase momentary blips in a stock price like this.

If you aren't running a fast trading scam you aren't being hurt by this.

It's not the like the normal up and down swings are based on anything beyond the emotional state of traders anyway.

As for users of fast trading algorithms getting burned... yay?

"Oddly no. One reason so few people die to terrorist incidents is that there's a lot of time and effort expended on preventing and mitigating against them."

There is absolutely no evidence to support that claim. As anti-terrorism efforts have heightened since 9/11 there has been an increase in terrorism from pre-9/11 not a reduction.

"Security vs. Liberty, It is always a tradeoff."

It's a trade I for one don't care to make. But this isn't just spying, this is creating fake attacks against our nation to make people THINK they are unsafe and trade away their liberty to the very groups that present the only real threat to it!

It is probably best to stop referring to the style guides as rules but rather as guidelines. One can reference guidelines and in some cases even require them but for the most part a guideline is not a requirement but a best practice which may have exceptions.

"Why? cause they are truly lazy and don't understand the tech skills needed for the job at hand."

That doesn't make them lazy, the only way to understand the tech skills needed for the job at hand is to have at or near the technical skills required to perform the task at hand.

It's not even a layer of HR, it's two because the hiring is all done via headhunters and they DEFINITELY have no idea what you'll be doing.

Points for restraint.

"Tor has done nothing but enable criminals ...read silk road trial?"

While technically silk road is enabling people to break laws it was formed as an act of civil disobedience to protest unjust laws. The fix for silk road is not to shut down privacy and tor, the fix for silk road is to shut down the laws that protect the existence of a black market. The federal government has no right to tell individuals what they can and can't do with their bodies. What is in the interest of the general welfare is to regulate manufacture and distribution in the same way they do with food and that can't happen so long as they outlaw the substances and thereby protect the black market.

Next you point to insurance costs due to negative health effects. Then I point to knee and hip replacements that are the result of years of excess physical exercise that cost dramatically more. Suggest we outlaw jogging and shut down gyms since it makes far more fiscal sense than outlawing drugs. Then I point to search and rescue, fireman, high rise construction workers, and high rise window washers and suggest we should outlaw people making the reckless decision to enter these jobs as well since we are calling the cumulative result of preventing individuals from taking individual risks the general welfare and bound to do so if we are to remain logically consistent.

"Am I the only one who thinks "the government" is actually made up of lots of independent minds, each with their own idealism and morality?"

That is the exact argument always levied against government conspiracies. It has been debunked thanks to the work of wikileaks, Mr. Snowden, and CIA revelation dumps. Anyone who didn't buy that argument, worked from the assumption you could trust those individuals to behave like any random stranger from the private sector showing up at your door at night, was sane, and intelligent would have come to the conclusion that these organizations were likely guilty of just about everything they turned out to be guilty of.

Government agencies might be populated with lots of independent minds but they are all basically structured like military or corporations with an executive structure. Every single day, every for profit corporation in the US is strategize to save costs, which translates in saving every penny at the expense of their workers they think they can spin without pushback. Year on year companies manage to slash health benefits for example. You don't need a conspiracy, the organization has interests which conflict with those of it's individual members and it's a significant portion of the population that is generally required to distrust the organization and it's spin in order push back against those interests.

So, get back to me when it proves to take a significant portion of the American population conspiring to prevent the illegal and unconstitutional spying revealed by Snowden from continuing. At this point the government is so corrupt that even the vast majority of the American population finding out about their conspiracies and being pissed about it has had ZERO impact beyond blowing some wind.

Also, the Navy and the NSA are one government organization. There is a reason the NSA director is always a high ranking military officer. How exactly does it take a significant portion of the American population to undermine a project built by a small group of people and paid for by the organization with interests that conflict with the rest of us?

"Well... whatever. How things work in the real world is that the graphics driver generates code in the ISA of the GPU, which the GPU then executes.

We won't see LLVM-in-hardware, for the same reason we don't see Java-in-hardware. Software compilers work well, and allow for hardware that's aimed at being really fast, not at accepting some inappropriate ISA. Also, that hardware wouldn't play nice with other APIs like Direct3D."

If the ISA of the GPU is byte code what stops the Direct3D SDK from generating it? It is the byte code and not LLVM I'm suggesting be implemented in hardware. A common instruction set similar to x86 in CPU land and just like in that space it only exists as a public interface that is then translated into optimized intel or AMD underlying magic on the chip almost immediately.

Or rather, an API agnostic open specification byte code that all API's can target. The benefit is obvious, if intel, amd, and nvidia all implement native hardware support for a common instruction set it not only provides a compatibility blanket that dramatically simplifies building better API's but it also dramatically simplifies producing drivers for their hardware.

"Especially since the bytecode is supposed to be hardware neutral, it is the compilation from bytecode that will have to do the aggresive optimizations to adapt to the target architecture."

This is a confusion in terms. Personally I blame Sun. An interpreter IS a form of compiler, it is the term used to refer compilation at run time. Which is exactly what happens here. That bytecode won't be interpreted or compiled before you open the game, therefore it is runtime compilation, therefore it is interpreting. JIT Compilation == Interpreted. The only difference between a compiler and an interpreter is when they perform compilation. What is happening here is the step happening in the sdk (compilation to bytecode) and the step happening in the graphics driver (bytecode, compiled at runtime aka interpreted, and then executed). Although both are technically compilation, classically you'd call one compilation due to all the work being done in advance and the other interpretation due to the work happening just before execution.

"building native execution of the bytecode would be fastest

Why not call this what it is? It's compilation."

I suppose if you are counting translating the machine code of the interpreter into logic gates and then physically building those gates on a wafer "compiling" that would be compilation.

As for hardware neutral, the api is a standard hardware neutral interface for developers. What difference does it make if the step which interprets the bytecode is executed as bare hardware or slower software? All software can be converted 1:1 to hardware. There are no optimizations which can be done here which wouldn't be comparable or even more efficient directly implemented in hardware. Initially it'd be a kludgy add on stealing chip die space (although not much in todays terms) but later the cards would be specifically designed to optimize the execution of that simple bytecode through the entire pipeline.

"I can't tell if you're just being obtuse, but: the developer compiles shader language to bytecode, and the graphics driver compiles bytecode to GPU native-code. Both of these stages qualify as compilation. (They're both level-reducing language-transformations.)"

Let me put this another way. Byte code is machine code for an imaginary machine, GPU native code is machine code for an actual machine. There is no level reduction occurring when interpreting byte code, both are already machine code, there is a translation from one instruction set to another compatible instruction set. Interpreters are a form of compiler designed to run at runtime rather than well in advance, modern interpreters are JIT compilers. The JVM for instance is an interpreter.

If you start confusing the typical convention of referring to compiled vs interpreted with the fact that technically in all cases the things you are referring to are all compilers it gets confusing. There is greater specificity in saying that bytecode in this case is run through an interpreter and even more specificity in saying that the design of that interpreter is one of JIT compilation (although the term mostly exists as a form of geek marketing to avoid negative stigma of using the word interpret).

"building native execution of the bytecode would be fastest

Why not call this what it is? It's compilation."

I'm not avoiding calling the translation compilation, as I clarified above, this is runtime compilation aka interpretation. I'm proposing that it would be faster to make the imaginary machines instruction set the instruction set physically implemented on the chip. As an intermediate but still ridiculously fast step they could add a handful of gates and perform the translation on the chip. The compiler would then be part of the SDK rather than part of the driver and you'd have compile once run everywhere shader code with the ability to hand optimize available to every developer.

It represents an excellent bit of bait to eventually get all GPU's to implement a standards based shader instruction set, much like Intel and AMD both target the same cpu instruction set.