Pass the 'Milk' to make code run four times faster, say MIT boffins

Interesting

To save others googling for more info, here's the article that the news sites are ripping off http://news.mit.edu/2016/faster-parallel-computing-big-data-0913

The 'good for big data' seems very significant - it's solving problems that happen with massive data sets so don't hope that this'll be eventually applied to small data to make your PC 4x faster

Milk for SQL ?

Language feature really?

Seems like a runtime system support feature. Good languages only have such things via library support?

I can't see how this can be described as an intrinsic feature of ANY programming language.

My skateboarding sheep and pirate friend will be happy

Software? Or maybe hardware.

So instead of just fetching the data, you're going to catch the request (in software?), and defer the code waiting for the data until the data can be more efficiently fetched.

Just how many more very expensive context switches will this generate? And where are the other threads that can be dispatched once all of them are waiting for an 'efficient data fetch'. And how will that affect the latency of individual threads?

I'm sure that there are some highly threaded applications with unpredictable data flow where this could be a benefit, but on the brute-force codes that make up most HPC applications, which mostly process data in predictable ways, especially Fortran code where the standard dictate how data is stored in arrays, this is likely to be completely unneeded extra code that can only slow the total throughput.

I think I'll let the hardware cache pre-fetch hardware provide all the speedup most real 'Big Data' requires.

...or CAFS ?

Lovely.

Milky milky.

So this means that Fortran and C are going to go the milky way?

I have no knowledge...

When it comes to expansive multi processing, I'm less than a novice, but what good does it do for a process to record the address it needs instead of requesting the data? Doesn't it need the data to continue it's processing? Now the compiler has to re-order the instructions to request all data first, then retrieve that data, THEN execute the computations on said data?

At some point, are we just asking too much of the compiler? Remember when Itanium was going to solve all our problems, only that pesky compiler wouldn't play along?

Sounds a lot like SCSI queue re-ordering to me.

Also, if the program needs the data before it can proceed, then what does it do before the cache has fetched it? Presumably blocks. OR do you have to register all your data requirements from the start? Not commonly easy to do.

That said, I've often thought that programmers write code in the order that make sense to them, but often the code can be completely re-ordered and still work the same, but I assumed modern compilers & processors also know this and do it already.

..and the difference between a language and a library is.....

A lot of software problems can be blamed on people not knowing the difference between languages, libraries, operating system components and so on.

"Milk" language

So it gets your code almost compiled, then stops right at the last second, waits a bit, then starts compiling again. Over and over and over. Is the purpose to fully compile, or delay the linker as long as possible? Hard to tell, as after a while your makefile is all smushy and disgusting. And when it finally DOES compile, it produces a much bigger binary than normal and you end up symbol-dumping all over the place.