doit

notes.org

@@ -4,7 +4,6 @@
 ** TODO Try to deploy
 ** TODO Put together POC for micro-caching RAILS
 ** TODO Create a ticket to deal with 403s for provisioning failures
-
 ** TODO Express concern around engineering quality
 
 I raised concerns that this result is doesn't meet the bar to achieve success on the problem we set out to solve.
@@ -33,3 +32,7 @@ Those people trying to raise the bar aren't doing so selfishly.
 We don't get immediate gain out of performing better or working harder, we still get paid the same.
 So why would we be striving to raise the bar? This is a fundamental question to see if a leader understands
 what high performers need to thrive.
+** TODO MAKE TICKETS
+scheduler
+worker configuration
+cleanup job

performance-aware-programming/notes.org

@@ -0,0 +1,37 @@
+#+TITLE: Performance-Aware Programming
+#+AUTHOR: Casey Muratori
+
+
+* Definition
+  Just knowing what you're doing can affect performance
+  Not doing actual low level performance optimization for specific hardware
+
+  "If you understand CSS you should understand this"
+
+* Thinking about the CPU
+
+If you think of a processor as a box which takes instructions as inputs
+and then they do some work before producing the output, you have two
+levers to pull for performance.
+
+1. Reduce the # of instructions
+   Simplify the program or generally reduce the work that the CPU needs
+2. Speed of the Instruction
+   Change the set of instructions you're passing through the CPU based
+   on how much time it might take to process.
+
+* Prologue
+
+In a simple python program below: We achieve ~0.006 adds/cycle
+
+#+begin_src python
+  def add(a, b):
+      a + b
+
+  c = 1234 + 5678
+#+end_src
+
+
+In the naive C version we're looking at ~0.8 adds/cycle
+
+If we get smarter and do some optimization with SIMD we can achive up to 16 adds/cycle.