4 ms·

> You can see these decisions being made by passing -gcflags=-m to go build: That's a very nice feature! I wonder if compilers for other languages have somethi

> You can see these decisions being made by passing -gcflags=-m to go build: That's a very nice feature! I wonder if compilers for other languages have something similar.

masklinn 4y ago
You'd have to see if all compilers support it, but LLVM has a "remarks" system, which should provide similar information (though likely a lot more of it) for optimization passes which are traced: https://llvm.org/docs/Remarks.html#introduction-to-the-llvm-remark-diagnostics https://llvm.org/docs/Remarks.html#introduction-to-the-llvm-... The frontend may or may not have its own optimizations and logs tho e.g. rustc now has MIR optimizations (https://rustc-dev-guide.rust-lang.org/mir/optimizations.html https://rustc-dev-guide.rust-lang.org/mir/optimizations.html) but while you can dump MIR data (https://rustc-dev-guide.rust-lang.org/mir/debugging.html https://rustc-dev-guide.rust-lang.org/mir/debugging.html) I don't remember seeing an optimisation log. At the end of the day, I think it's more likely that you take a look at the assembly and infer problems from there if the profiler doesn't tell you straight. An other difference is the kind of decisions the compiler makes e.g. while a compiler can optimize away allocations in "manual allocation" languages (https://godbolt.org/z/5nEo7xjEr https://godbolt.org/z/5nEo7xjEr) the allocations are plainly visible, so if they're trivially avoidable... you'll just avoid them. Using Rust as an example, you'd have something like this: pub fn match_(&self, path: &str) -> Result<&Rule, Error> { for rule in self.0.iter() { if rule.match_(path)? { return Ok(rule); } } Err(Error) } You couldn't miss an allocation, because the return type would have to change, and you'd need to perform the copy out: pub fn match_(&self, path: &str) -> Result<Box<Rule>, Error> { for rule in self.0.iter() { if rule.match_(path)? { return Ok(Box::new(rule.clone())); } } Err(Error) }
_old_dude_ 4y ago
In Java -XX:+PrintCompilation -XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining and -XX:+UnlockDiagnosticVMOptions -XX:+LogCompilation The generated logs can be seen with JITWatch [1]. [1] https://github.com/AdoptOpenJDK/jitwatch https://github.com/AdoptOpenJDK/jitwatch
throwaway894345 4y ago
Does anyone with VS Code or vim plugin development experience know how hard it would be to call this behind the scenes and highlight allocation points in the editor?

> You can see these decisions being made by passing -gcflags=-m to go build: That's a very nice feature! I wonder if compilers for other languages have something similar.

masklinn 4y ago

You'd have to see if all compilers support it, but LLVM has a "remarks" system, which should provide similar information (though likely a lot more of it) for optimization passes which are traced: https://llvm.org/docs/Remarks.html#introduction-to-the-llvm-remark-diagnostics https://llvm.org/docs/Remarks.html#introduction-to-the-llvm-... The frontend may or may not have its own optimizations and logs tho e.g. rustc now has MIR optimizations (https://rustc-dev-guide.rust-lang.org/mir/optimizations.html https://rustc-dev-guide.rust-lang.org/mir/optimizations.html) but while you can dump MIR data (https://rustc-dev-guide.rust-lang.org/mir/debugging.html https://rustc-dev-guide.rust-lang.org/mir/debugging.html) I don't remember seeing an optimisation log. At the end of the day, I think it's more likely that you take a look at the assembly and infer problems from there if the profiler doesn't tell you straight. An other difference is the kind of decisions the compiler makes e.g. while a compiler can optimize away allocations in "manual allocation" languages (https://godbolt.org/z/5nEo7xjEr https://godbolt.org/z/5nEo7xjEr) the allocations are plainly visible, so if they're trivially avoidable... you'll just avoid them. Using Rust as an example, you'd have something like this: pub fn match_(&self, path: &str) -> Result<&Rule, Error> { for rule in self.0.iter() { if rule.match_(path)? { return Ok(rule); } } Err(Error) } You couldn't miss an allocation, because the return type would have to change, and you'd need to perform the copy out: pub fn match_(&self, path: &str) -> Result<Box<Rule>, Error> { for rule in self.0.iter() { if rule.match_(path)? { return Ok(Box::new(rule.clone())); } } Err(Error) }

_old_dude_ 4y ago

In Java -XX:+PrintCompilation -XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining and -XX:+UnlockDiagnosticVMOptions -XX:+LogCompilation The generated logs can be seen with JITWatch [1]. [1] https://github.com/AdoptOpenJDK/jitwatch https://github.com/AdoptOpenJDK/jitwatch

throwaway894345 4y ago

Does anyone with VS Code or vim plugin development experience know how hard it would be to call this behind the scenes and highlight allocation points in the editor?