malcolmgreaves · February 18, 2025 19:31 · malcolmgreaves · Feb 18, 2025 · malcolmgreaves · Feb 18, 2025
diff --git a/rust_impl_vs_dyn_function_parameter.rs b/rust_impl_vs_dyn_function_parameter.rs
 fn foo() -> impl Fn(i32) -> i32 {
    |x| x + 1
 }

 fn bar(f: &impl Fn(i32) -> i32) -> i32 {
   f(10)
 }

 fn baz(f: &dyn Fn(i32) -> i32) -> i32 {
  f(10)
 }

 pub fn main() {
  let f = foo();
  println!("foo()(10):       {}", f(10));
  println!("from bar: f(10): {}", bar(&f));
  println!("from baz: f(10): {}", baz(&f));
 }

 // Compile and run:
 //    $ rustc rust_impl_vs_dyn_function_parameter.rs && ./rust_impl_vs_dyn_function_parameter
 // Produces:
 //    foo()(10):       11
 //    from bar: f(10): 11
 //    from baz: f(10): 11

 /*

 # Assembly Code
 Let's take a look at the compiled assembly code for bar vs. baz! (aka impl vs dyn for a function pointer!)
 ---------------------
 - get assembly code using `objdump`: `objdump -D ./rust_impl_vs_dyn_function_parameter`
 - grep for "bar" and "baz"


 Here's the generated assembly when we use `&impl TRAIT`:
 --------------------------------------------------------
 000000010000446c <__ZN1y3bar17hd084ba6d3d1efec4E>:
 10000446c: a9bf7bfd    	stp	x29, x30, [sp, #-0x10]!
 100004470: 910003fd    	mov	x29, sp
 100004474: 52800141    	mov	w1, #0xa                ; =10
 100004478: 97ffffee    	bl	0x100004430 <__ZN1y3foo28_$u7b$$u7b$closure$u7d$$u7d$17h54096ff91efe5082E>
 10000447c: a8c17bfd    	ldp	x29, x30, [sp], #0x10
 100004480: d65f03c0    	ret
 --------------------------------------------------------

 Notice that we have only 1 instruction for invoking our closure:
    (1) call the closure generated by `foo`

 Here's the generated assembly when we use `&dyn TRAIT`:
 --------------------------------------------------------
 0000000100004484 <__ZN1y3baz17hc9afa0533ff6b436E>:
 100004484: a9bf7bfd    	stp	x29, x30, [sp, #-0x10]!
 100004488: 910003fd    	mov	x29, sp
 10000448c: f9401428    	ldr	x8, [x1, #0x28]
 100004490: 52800141    	mov	w1, #0xa                ; =10
 100004494: d63f0100    	blr	x8
 100004498: a8c17bfd    	ldp	x29, x30, [sp], #0x10
 10000449c: d65f03c0    	ret
 --------------------------------------------------------

 Notice that here we have 2 distinct instructions for invoking `f(10)`:
  (1) load the address to the closure into a register (`ldr`)
  (2) invoke the function loaded in the register (`blr`)

 In both cases, we have the same number of instructions for setting up the stack of parameters to our closure.
 We put the input value, 10, into a register (mov w1, #0xA). Note that it uses the literal 10 value, written out
 here in hexadecimal.

 # Why?
 Why is there a difference? Why does the `dyn` version take 2 instructions to call the closure when the `impl` 
 version only takes 1?

 This is because `dyn` means dynamic dispatch. It must have a pointer to the data as well as the virtual function
 table. The address of these **cannot** be known statically. Thus, in `baz`, the compilier must always have a
 **procedure** it runs in order to determine where the closure exists so it can invoke it.

 In contrast, when we use `impl`, we are **hiding** the concrete type behind the trait. However, __(1) this type
 exists and (2) the compiler knows about it!_. It is a **unique, unnamed type** from the compiler's perspective.
 This means the `rustc` can statically link the closure returned by foo in `bar`.

 # Tradeoffs?
 Dynamic dispatch requires 2 pointers (location of data, location of virtual function lookup table) whereas static
 dispatch only requires 1 (where in the binary the function starts). It'll also require 1 additional instruction.

 Dynamic dispatch reduces binary bloat compared to using exestential types (i.e. `impl TRAIT`). For the latter, the
 compiler makes *a new* type for each place it's written & used in the source code. In the former's case, a unique
 type needn't be created, leading the way for more reuse in binary form.
 */
	fn foo() -> impl Fn(i32) -> i32 {
	\|x\| x + 1
	}

	fn bar(f: &impl Fn(i32) -> i32) -> i32 {
	f(10)
	}

	fn baz(f: &dyn Fn(i32) -> i32) -> i32 {
	f(10)
	}

	pub fn main() {
	let f = foo();
	println!("foo()(10): {}", f(10));
	println!("from bar: f(10): {}", bar(&f));
	println!("from baz: f(10): {}", baz(&f));
	}

	// Compile and run:
	// $ rustc rust_impl_vs_dyn_function_parameter.rs && ./rust_impl_vs_dyn_function_parameter
	// Produces:
	// foo()(10): 11
	// from bar: f(10): 11
	// from baz: f(10): 11

	/*

	# Assembly Code
	Let's take a look at the compiled assembly code for bar vs. baz! (aka impl vs dyn for a function pointer!)
	---------------------
	- get assembly code using `objdump`: `objdump -D ./rust_impl_vs_dyn_function_parameter`
	- grep for "bar" and "baz"


	Here's the generated assembly when we use `&impl TRAIT`:
	--------------------------------------------------------
	000000010000446c <__ZN1y3bar17hd084ba6d3d1efec4E>:
	10000446c: a9bf7bfd stp x29, x30, [sp, #-0x10]!
	100004470: 910003fd mov x29, sp
	100004474: 52800141 mov w1, #0xa ; =10
	100004478: 97ffffee bl 0x100004430 <__ZN1y3foo28_$u7b$$u7b$closure$u7d$$u7d$17h54096ff91efe5082E>
	10000447c: a8c17bfd ldp x29, x30, [sp], #0x10
	100004480: d65f03c0 ret
	--------------------------------------------------------

	Notice that we have only 1 instruction for invoking our closure:
	(1) call the closure generated by `foo`

	Here's the generated assembly when we use `&dyn TRAIT`:
	--------------------------------------------------------
	0000000100004484 <__ZN1y3baz17hc9afa0533ff6b436E>:
	100004484: a9bf7bfd stp x29, x30, [sp, #-0x10]!
	100004488: 910003fd mov x29, sp
	10000448c: f9401428 ldr x8, [x1, #0x28]
	100004490: 52800141 mov w1, #0xa ; =10
	100004494: d63f0100 blr x8
	100004498: a8c17bfd ldp x29, x30, [sp], #0x10
	10000449c: d65f03c0 ret
	--------------------------------------------------------

	Notice that here we have 2 distinct instructions for invoking `f(10)`:
	(1) load the address to the closure into a register (`ldr`)
	(2) invoke the function loaded in the register (`blr`)

	In both cases, we have the same number of instructions for setting up the stack of parameters to our closure.
	We put the input value, 10, into a register (mov w1, #0xA). Note that it uses the literal 10 value, written out
	here in hexadecimal.

	# Why?
	Why is there a difference? Why does the `dyn` version take 2 instructions to call the closure when the `impl`
	version only takes 1?

	This is because `dyn` means dynamic dispatch. It must have a pointer to the data as well as the virtual function
	table. The address of these cannot be known statically. Thus, in `baz`, the compilier must always have a
	procedure it runs in order to determine where the closure exists so it can invoke it.

	In contrast, when we use `impl`, we are hiding the concrete type behind the trait. However, __(1) this type
	exists and (2) the compiler knows about it!_. It is a unique, unnamed type from the compiler's perspective.
	This means the `rustc` can statically link the closure returned by foo in `bar`.

	# Tradeoffs?
	Dynamic dispatch requires 2 pointers (location of data, location of virtual function lookup table) whereas static
	dispatch only requires 1 (where in the binary the function starts). It'll also require 1 additional instruction.

	Dynamic dispatch reduces binary bloat compared to using exestential types (i.e. `impl TRAIT`). For the latter, the
	compiler makes a new type for each place it's written & used in the source code. In the former's case, a unique
	type needn't be created, leading the way for more reuse in binary form.
	*/