Design and Implementation of a 256-Core BrainFuck Computer [pdf]

http://www.scottaaronson.com/blog/?p=1400

https://news.mit.edu/2015/3q-scott-aaronson-google-quantum-c...

In second, this jumps out at me: "The first issue is that the problem instances where the comparison is being done are basically for the problem of simulating the D-Wave machine itself. There were $150 million dollars that went into designing this special-purpose hardware for this D-Wave machine and making it as fast as possible. So in some sense, it’s no surprise that this special-purpose hardware could get a constant-factor speedup over a classical computer for the problem of simulating itself."

Actually gives me an idea. Instead of comparison to BF competitors, I could actually just compare a massively-parallel, BF CPU to 256 interpreters communicating with each other through IPC running on a general-purpose computer. I'd show the CPU performed many times better. It's the closest thing I can think of to how D-Wave is doing benchmarking. The difference is $150 million is not in either my bank account or addition of transaction history.

"One interesting factoid is that they were able to translate Wikipedia in its entirety from English to Russian using 90% of the currently deployed FPGAs in around 100 ms. Insane stuff."

Didn't know about that project. Pretty cool. Yeah, the FPGA projects have been doing all kinds of stuff like that going back to at least the 90's from my reading. The speedups could be over fifty fold. Some claimed three digits. Other programs harder to parallelize & reduce... which is basically what they do on FPGA... might have under 100% speed up, tiny speed up, or even a loss if it was sequential algorithm vs ultra-optimized, sequential CPU like Intel's. The latest work, which started in 90's projects I believe, was to create software that automatically synthesizes FPGA logic from the fast path of applications in a high-level language then glues them into the regular application on a regular CPU. You can't get speed-up of actual hardware design but makes boosts easier if problem supports good synthesis. Tensilica is another example of a company whose Xtensa CPU is one that's customized... from CPU to compilation toolchain... to fit your application. Container people are compiling and delivering containers. Tensilica compiles and delivers apps with a custom CPU.

That's actually the point of my plan. :P

That's a great expansion it being undocumented. Worked wonders for Microsoft's strategy of lock-in. We're going to have to make sure the CPU and platform's API's are considered copywritten on top of that so they might not be... legally allowed... to clone or port it without paying us. We could collect royalties on a BrainFuck CPU for our lifetime plus an arbitrary number of years decided by Congress reps collecting bribes.

On a daily basis, the worst I have to deal with is SystemD, which is creatively incompotent and best, and downright insane at worst. But it's got a pretty face, and the draw of easy-to-understand unit files (over, say, SVinit), so people don't realize the depths of the madness that lies beneath.

It is a compiler and OS. Easy means a different thing in this context versus average usage in software. I'd say vastly easier than trying to understand GCC or Linux. How about that? Also, the original version was done by 2 people and some change. Each port of compiler was done by 1-2 people in relatively short time. Mostly students with basic knowledge in CompSci. Helps it's well-documented.

So, it's not easy as throwing together a web app but can't be ridiculously hard if you take it a piece at a time. The use I had for it, other than learning or pleasure, would be for subversion-resistent, verified-to-assembly builds. It's super easy to learn Oberon with the OS itself straight-forward. People could code it up in a local language, the compiler too, compile those (or hand-done in ASM), and bootstrap into a trusted environment. That can be used to produce the rest with compilers built on top in a memory-safe language that handles foreign code more safely. Better, no patent suits or anything on Wirth-based tech like .NET or Java might get you.

Other than Oberon system, Modula-3 (not Wirth) and Component Pascal (Wirth et al) are most worthwhile to check out in terms of practical languages. BlackBox Component Builder is still in active use with Component Pascal, esp in Russia and Europe. They love it over there since it's got OOP & GUI with Oberon simplicity & safety.