MIT's New Tool Predicts How Fast a Chip Can Run Your Code

Folks at the Massachusetts Institute of Technology (MIT) have developed a new machine learning-based tool that will tell you how fast a code can run on various chips. This will help developers tune their applications for specific processor architectures. From a report: Traditionally, developers used the performance model of compilers through a simulation to run basic blocks -- fundamental computer instruction at the machine level -- of code in order to gauge the performance of a chip. However, these performance models are not often validated through real-life processor performance. MIT researchers developed an AI model called Ithmel by training it to predict how fast a chip can run unknown basic blocks. Later, it was supported by a database called BHive with 300,000 basic blocks from specialized fields such as machine learning, cryptography, and graphics. The team of researchers presented a paper [PDF] at the NeuralIPS conference in December to describe a new technique to measure code performance on various processors. The paper also describes Vemal, a new automatically generating algorithm that can be used to generate compiler optimizations.

Fixing the "File copy" progress bar?

[Pascoea]

Does this mean they are finally close to fixing the progress bar for copying files in Windows?

Re:Fixing the "File copy" progress bar?

[Gravis Zero]

Does this mean they are finally close to fixing the progress bar for copying files in Windows?

Yes, it will be fixed in 10 minu-3 year, 8 days an-58 days-2 minutes-400 years...

What crap

[shibbie]

Performance these days isn't primarily CPU bound, it's how well it can run a database, how fast a network cache is, how well the OS performs scheduling and paging (if required). The external influences have much greater impact on program speed than on how fast a CPU can run code, kind of like trying to optimise the wrong thing, when CPU type, cache, cores and MHz will likely to be just as good and quicker general indicator.

Re:What crap

[Dutch Gun]

Not everything is a web app or a front-end to a giant database. There are plenty of applications that are CPU (and GPU) bound, not network bound. Videogames are an example of such (except for streamed games).

Re:

[K. S. Kyosuke]

And a hammer will be piss-poor at screwing bolts. So what? That's not what these tools are for. Use the right tool for the job.

Replace simulation with simulation

[Way Smarter Than You]

So.... they say the problem with current techniques is they don't test real world performance.... uhm, so, doing guesswork based on other code in a library and adding "magical AI buzzword" is different how? Still not real world.

Help devs tune their code? Yeah, right.

[Viol8]

Cross platform compiled development is hard enough with different compilers, compilation options and library issues without having to worry about tuning code for a given CPU. THAT is the compiler writers problem - the days of hand crafted assembler are long gone except for niche use cases. And if you're using java or a scripting language such as Python the CPU is a complete irrelevance. And then there is the whole other area of binaries running on VMs.

Re:

[K. S. Kyosuke]

Uhh...but this clearly *is* a tool for compiler writers. You don't need flawed guesswork if you've derived your cost model from real-world measurements, and a compiler can use a better cost model to decide if certain implementations are worth it.

Re:

[K. S. Kyosuke]

"If certain optimizations are worth it", dammit.

It already runs terribly

[darkain]

We already have something called "bhyve", it is the BSD Hypervisor. C'mon teams, if you're going to publish this shit, at LEAST do a 30 second search to see if they name is already being used in a strikingly similar field to your own. And this isn't the normal case of things using common words, it is a very specific mis-spelling of a word.

Re:

[Cipheron]

This BHive database is in a very narrowly specialized field. The chance of it being confused with a BSD Hypervisor project called Bhyve is literally zero. It's not a "strikingly similar field" at all.