mirror of
https://github.com/bspeice/speice.io
synced 2024-11-14 22:18:10 -05:00
1 line
9.1 KiB
JavaScript
1 line
9.1 KiB
JavaScript
"use strict";(self.webpackChunkspeice_io=self.webpackChunkspeice_io||[]).push([["5407"],{3561:function(e,t,n){n.r(t),n.d(t,{assets:function(){return l},contentTitle:function(){return r},default:function(){return d},frontMatter:function(){return s},metadata:function(){return o},toc:function(){return c}});var o=n(9395),a=n(5893),i=n(65);let s={title:"Allocations in Rust: Compiler optimizations",description:"A lot. The answer is a lot.",date:new Date("2019-02-08T12:00:00.000Z"),last_updated:{date:new Date("2019-02-10T12:00:00.000Z")},tags:[]},r=void 0,l={authorsImageUrls:[]},c=[{value:"The Case of the Disappearing Box",id:"the-case-of-the-disappearing-box",level:2},{value:"Dr. Array or: how I learned to love the optimizer",id:"dr-array-or-how-i-learned-to-love-the-optimizer",level:2}];function h(e){let t={a:"a",code:"code",em:"em",h2:"h2",p:"p",pre:"pre",strong:"strong",...(0,i.a)(),...e.components};return(0,a.jsxs)(a.Fragment,{children:[(0,a.jsx)(t.p,{children:"Up to this point, we've been discussing memory usage in the Rust language by focusing on simple\nrules that are mostly right for small chunks of code. We've spent time showing how those rules work\nthemselves out in practice, and become familiar with reading the assembly code needed to see each\nmemory type (global, stack, heap) in action."}),"\n",(0,a.jsx)(t.p,{children:"Throughout the series so far, we've put a handicap on the code. In the name of consistent and\nunderstandable results, we've asked the compiler to pretty please leave the training wheels on. Now\nis the time where we throw out all the rules and take off the kid gloves. As it turns out, both the\nRust compiler and the LLVM optimizers are incredibly sophisticated, and we'll step back and let them\ndo their job."}),"\n",(0,a.jsxs)(t.p,{children:["Similar to\n",(0,a.jsx)(t.a,{href:"https://www.youtube.com/watch?v=bSkpMdDe4g4",children:'"What Has My Compiler Done For Me Lately?"'}),", we're\nfocusing on interesting things the Rust language (and LLVM!) can do with memory management. We'll\nstill be looking at assembly code to understand what's going on, but it's important to mention\nagain: ",(0,a.jsxs)(t.strong,{children:["please use automated tools like ",(0,a.jsx)(t.a,{href:"https://crates.io/crates/alloc_counter",children:"alloc-counter"})," to\ndouble-check memory behavior if it's something you care about"]}),". It's far too easy to mis-read\nassembly in large code sections, you should always verify behavior if you care about memory usage."]}),"\n",(0,a.jsxs)(t.p,{children:["The guiding principal as we move forward is this: ",(0,a.jsx)(t.em,{children:"optimizing compilers won't produce worse programs\nthan we started with."})," There won't be any situations where stack allocations get moved to heap\nallocations. There will, however, be an opera of optimization."]}),"\n",(0,a.jsxs)(t.p,{children:[(0,a.jsx)(t.strong,{children:"Update 2019-02-10"}),": When debugging a\n",(0,a.jsx)(t.a,{href:"https://gitlab.com/sio4/code/alloc-counter/issues/1",children:"related issue"}),", it was discovered that the\noriginal code worked because LLVM optimized out the entire function, rather than just the allocation\nsegments. The code has been updated with proper use of\n",(0,a.jsx)(t.a,{href:"https://doc.rust-lang.org/std/ptr/fn.read_volatile.html",children:(0,a.jsx)(t.code,{children:"read_volatile"})}),", and a previous section\non vector capacity has been removed."]}),"\n",(0,a.jsx)(t.h2,{id:"the-case-of-the-disappearing-box",children:"The Case of the Disappearing Box"}),"\n",(0,a.jsxs)(t.p,{children:["Our first optimization comes when LLVM can reason that the lifetime of an object is sufficiently\nshort that heap allocations aren't necessary. In these cases, LLVM will move the allocation to the\nstack instead! The way this interacts with ",(0,a.jsx)(t.code,{children:"#[inline]"})," attributes is a bit opaque, but the important\npart is that LLVM can sometimes do better than the baseline Rust language:"]}),"\n",(0,a.jsx)(t.pre,{children:(0,a.jsx)(t.code,{className:"language-rust",children:'use std::alloc::{GlobalAlloc, Layout, System};\nuse std::sync::atomic::{AtomicBool, Ordering};\n\npub fn cmp(x: u32) {\n // Turn on panicking if we allocate on the heap\n DO_PANIC.store(true, Ordering::SeqCst);\n\n // The compiler is able to see through the constant `Box`\n // and directly compare `x` to 24 - assembly line 73\n let y = Box::new(24);\n let equals = x == *y;\n\n // This call to drop is eliminated\n drop(y);\n\n // Need to mark the comparison result as volatile so that\n // LLVM doesn\'t strip out all the code. If `y` is marked\n // volatile instead, allocation will be forced.\n unsafe { std::ptr::read_volatile(&equals) };\n\n // Turn off panicking, as there are some deallocations\n // when we exit main.\n DO_PANIC.store(false, Ordering::SeqCst);\n}\n\nfn main() {\n cmp(12)\n}\n\n#[global_allocator]\nstatic A: PanicAllocator = PanicAllocator;\nstatic DO_PANIC: AtomicBool = AtomicBool::new(false);\nstruct PanicAllocator;\n\nunsafe impl GlobalAlloc for PanicAllocator {\n unsafe fn alloc(&self, layout: Layout) -> *mut u8 {\n if DO_PANIC.load(Ordering::SeqCst) {\n panic!("Unexpected allocation.");\n }\n System.alloc(layout)\n }\n\n unsafe fn dealloc(&self, ptr: *mut u8, layout: Layout) {\n if DO_PANIC.load(Ordering::SeqCst) {\n panic!("Unexpected deallocation.");\n }\n System.dealloc(ptr, layout);\n }\n}\n'})}),"\n",(0,a.jsxs)(t.p,{children:["-- ",(0,a.jsx)(t.a,{href:"https://godbolt.org/z/BZ_Yp3",children:"Compiler Explorer"})]}),"\n",(0,a.jsxs)(t.p,{children:["-- ",(0,a.jsx)(t.a,{href:"https://play.rust-lang.org/?version=stable&mode=release&edition=2018&gist=4a765f753183d5b919f62c71d2109d5d",children:"Rust Playground"})]}),"\n",(0,a.jsx)(t.h2,{id:"dr-array-or-how-i-learned-to-love-the-optimizer",children:"Dr. Array or: how I learned to love the optimizer"}),"\n",(0,a.jsxs)(t.p,{children:["Finally, this isn't so much about LLVM figuring out different memory behavior, but LLVM stripping\nout code that doesn't do anything. Optimizations of this type have a lot of nuance to them; if\nyou're not careful, they can make your benchmarks look\n",(0,a.jsx)(t.a,{href:"https://www.youtube.com/watch?v=nXaxk27zwlk&feature=youtu.be&t=1199",children:"impossibly good"}),". In Rust, the\n",(0,a.jsx)(t.code,{children:"black_box"})," function (implemented in both\n",(0,a.jsx)(t.a,{href:"https://doc.rust-lang.org/1.1.0/test/fn.black_box.html",children:(0,a.jsx)(t.code,{children:"libtest"})})," and\n",(0,a.jsx)(t.a,{href:"https://docs.rs/criterion/0.2.10/criterion/fn.black_box.html",children:(0,a.jsx)(t.code,{children:"criterion"})}),") will tell the compiler\nto disable this kind of optimization. But if you let LLVM remove unnecessary code, you can end up\nrunning programs that previously caused errors:"]}),"\n",(0,a.jsx)(t.pre,{children:(0,a.jsx)(t.code,{className:"language-rust",children:"#[derive(Default)]\nstruct TwoFiftySix {\n _a: [u64; 32]\n}\n\n#[derive(Default)]\nstruct EightK {\n _a: [TwoFiftySix; 32]\n}\n\n#[derive(Default)]\nstruct TwoFiftySixK {\n _a: [EightK; 32]\n}\n\n#[derive(Default)]\nstruct EightM {\n _a: [TwoFiftySixK; 32]\n}\n\npub fn main() {\n // Normally this blows up because we can't reserve size on stack\n // for the `EightM` struct. But because the compiler notices we\n // never do anything with `_x`, it optimizes out the stack storage\n // and the program completes successfully.\n let _x = EightM::default();\n}\n"})}),"\n",(0,a.jsxs)(t.p,{children:["-- ",(0,a.jsx)(t.a,{href:"https://godbolt.org/z/daHn7P",children:"Compiler Explorer"})]}),"\n",(0,a.jsxs)(t.p,{children:["-- ",(0,a.jsx)(t.a,{href:"https://play.rust-lang.org/?version=stable&mode=release&edition=2018&gist=4c253bf26072119896ab93c6ef064dc0",children:"Rust Playground"})]})]})}function d(e={}){let{wrapper:t}={...(0,i.a)(),...e.components};return t?(0,a.jsx)(t,{...e,children:(0,a.jsx)(h,{...e})}):h(e)}},65:function(e,t,n){n.d(t,{Z:function(){return r},a:function(){return s}});var o=n(7294);let a={},i=o.createContext(a);function s(e){let t=o.useContext(i);return o.useMemo(function(){return"function"==typeof e?e(t):{...t,...e}},[t,e])}function r(e){let t;return t=e.disableParentContext?"function"==typeof e.components?e.components(a):e.components||a:s(e.components),o.createElement(i.Provider,{value:t},e.children)}},9395:function(e){e.exports=JSON.parse('{"permalink":"/2019/02/08/compiler-optimizations","source":"@site/blog/2019-02-08-compiler-optimizations/index.mdx","title":"Allocations in Rust: Compiler optimizations","description":"A lot. The answer is a lot.","date":"2019-02-08T12:00:00.000Z","tags":[],"readingTime":3.695,"hasTruncateMarker":true,"authors":[],"frontMatter":{"title":"Allocations in Rust: Compiler optimizations","description":"A lot. The answer is a lot.","date":"2019-02-08T12:00:00.000Z","last_updated":{"date":"2019-02-10T12:00:00.000Z"},"tags":[]},"unlisted":false,"lastUpdatedAt":1731204300000,"prevItem":{"title":"Allocations in Rust: Summary","permalink":"/2019/02/summary"},"nextItem":{"title":"Allocations in Rust: Dynamic memory","permalink":"/2019/02/a-heaping-helping"}}')}}]); |