tag:luciotato.svbtle.com,2014:/feedLucio Tato2015-02-03T07:11:49-08:00Lucio Tatohttps://luciotato.svbtle.comSvbtle.comtag:luciotato.svbtle.com,2014:Post/golangs-duffs-devices2015-02-03T07:11:49-08:002015-02-03T07:11:49-08:00golang Duff's devices<p>I’m just starting to scratch golang surface, and until now it has been a <a href="http://luciotato.svbtle.com/golang-first-impressions">pleasant experience</a>.</p>
<p>golang feels <em>solid</em> and <em>fast</em>.</p>
<p>Let me share with you a few golang internals on this notes as long as I’m stumbling upon them: </p>
<p>Today I’ve tripped over some golang source code that looks like a copy-paste frenzy, but is a very clever assembler trick to make the processor go as fast as possible:</p>
<p>The code is in runtime/asm_amd64.s and looks like this:</p>
<pre><code class="prettyprint"> STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
...
</code></pre>
<p>… repeated <del>128</del> 2<sup>7</sup> times</p>
<p>and later:</p>
<pre><code class="prettyprint"> MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
...
</code></pre>
<p>… repeated, again, 2<sup>7</sup> times, (512 LOC)</p>
<p>It turns out that this is a clever trick called “A Duff’s device”. Wow! today we’re learning very low-level stuff.</p>
<p>If this is the trickery level of golang, <em>no wonder why is so fast!</em></p>
<p>I’ll paste the code at the end of this post, and you can google Duff’s device yourself, but before that, let me share a warning snippet I’ve found on source comments: <strong><em>Keep your hands off vprintf! :)</em></strong> </p>
<p><em>at runtime\print1.go:</em><br></p>
<blockquote>
<p>// Very simple printf. Only for debugging prints.<br> <br>
// <strong><em>Do not add to this without checking with Rob.</em></strong><br><br>
func vprintf(str string, arg unsafe.Pointer)…* </p>
</blockquote>
<p><strong><em>And now for something completely different:</em></strong> Here is the full code section with the Duff’s devices from runtime/asm_amd64.s, for your viewing pleasure:</p>
<pre><code class="prettyprint">// A Duff's device for zeroing memory.
// The compiler jumps to computed addresses within
// this routine to zero chunks of memory. Do not
// change this code without also changing the code
// in ../../cmd/6g/ggen.c:clearfat.
// AX: zero
// DI: ptr to memory to be zeroed
// DI is updated as a side effect.
TEXT runtime·duffzero(SB), NOSPLIT, $0-0
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
STOSQ
RET
// A Duff's device for copying memory.
// The compiler jumps to computed addresses within
// this routine to copy chunks of memory. Source
// and destination must not overlap. Do not
// change this code without also changing the code
// in ../../cmd/6g/cgen.c:sgen.
// SI: ptr to source memory
// DI: ptr to destination memory
// SI and DI are updated as a side effect.
// NOTE: this is equivalent to a sequence of MOVSQ but
// for some reason that is 3.5x slower than this code.
// The STOSQ above seem fine, though.
TEXT runtime·duffcopy(SB), NOSPLIT, $0-0
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
MOVQ (SI),CX
ADDQ $8,SI
MOVQ CX,(DI)
ADDQ $8,DI
RET
</code></pre>
tag:luciotato.svbtle.com,2014:Post/golang-first-impressions2015-02-03T07:06:30-08:002015-02-03T07:06:30-08:00golang first impressions<p>What did I do with golang until now:</p>
<ul>
<li><p>Install on linux? great: fast, seamless.</p></li>
<li><p>Workspace organization? great, simple, clean (wks/src, wks/bin, wks/pkg, and also wsk/src/github.com/user/project)</p></li>
<li><p>Compile on linux? (small test programs) great: code auto formatted, then a multi-threaded 64-bit executable produced and installed on a single command in milliseconds.</p></li>
<li><p>get golang source on linux? no problem.</p></li>
<li><p>Compile golang source on Linux? no problem (I did this to cross-compile the multi-thread test as 32-bit exe on a 64-bit machine, to test torn-reads… but this is for another post)</p></li>
<li><p>Install on windows? fast, seamless.</p></li>
<li><p>Compile on windows the same small tests? no problem.</p></li>
</ul>
tag:luciotato.svbtle.com,2014:Post/iteration-vs-recursion2015-01-07T12:20:22-08:002015-01-07T12:20:22-08:00Iteration vs. Recursion, from scratch<p><em>I’ve read in the interwebs than iteration or recursion is a matter of choice, … that they are somewhat “equivalent”…</em></p>
<p>I don’t think so.</p>
<p>Let’s compare “Iteration” vs “Recursion” by analyzing which core concepts are required to <em>implement</em> each one of this concepts:</p>
<p>Let’s start from scratch:</p>
<blockquote class="short">
<p><strong>Question</strong>: What do yo need to <em>compute</em> something, to follow an algorithm and reach a result?</p>
</blockquote>
<p>We will try to establish a hierarchy of concepts, starting from scratch and defining in first place the basic, core concepts and after that the concepts which are constructed from previously defined concepts.</p>
<ol>
<li><p><strong>State: Memory cells, storage</strong>: to do something you need <em>places</em> to store final and intermediate result values. Let’s assume we have an infinite array of “integer” cells, called <strong>Memory</strong>, M[0..Infinite]. </p></li>
<li>
<p><strong>Instructions:</strong> do something - transform a cell, change its value. <strong>alter state</strong>. Every interesting instruction performs a transformation. Basic instructions are:</p>
<p>a) <strong>Set & move memory cells (alter State)</strong> </p>
<ul>
<li>store a value into memory, e.g.: <strong><em>store 5 m[4]</em></strong> </li>
<li>copy a value to another position: e.g.: <strong><em>store m[4] m[8]</em></strong> </li>
</ul>
<p>b) <strong>Logic and arithmetic</strong></p>
<ul>
<li>and, or, xor, not</li>
<li>add, sub, mul, div</li>
</ul>
</li>
<li><p><strong>A Executing Agent</strong>: a <em>core</em> in a modern CPU. An “agent” is something that can execute instructions. An <em>Agent</em> can also be a person following the algorithm on paper.</p></li>
<li>
<p><strong>Steps: a sequence of instructions</strong>: i.e.: do this first, do this after, etc. An imperative sequence of instructions. Even one line <em>expressions</em> are an imperative sequence of instructions. If you have a expression with a specific “order of evaluation” then you have <strong><em>steps</em></strong>. It means than even a single composed expression has implicit “steps” and also an implicit local variable (let’s call it “result”). </p>
<pre><code class="prettyprint">4 + 3 * 2 - 5
(- (+ (* 3 2) 4 ) 5)
(sub (add (mul 3 2) 4 ) 5)
</code></pre>
<p>The expression above implies 3 steps with an implicit “result” variable.</p>
<pre><code class="prettyprint">// pseudocode
1. result = (mul 3 2)
2. result = (add 4 result)
3. result = (sub result 5)
</code></pre>
<p>So even infix expressions, if you have a specific order of evaluation, are <em>an imperative sequence of instructions</em>. The expression <em>implies</em> a sequence of operations to be made in a specific order, and because there are <em>steps</em>, there is also an implicit “result” intermediate variable.</p>
</li>
<li>
<p><strong>Instruction Pointer</strong>: If you have a sequence of steps, you have also an implicit “instruction pointer”. The instruction pointer marks the next instruction, and advances after the instruction is read but before the instruction is executed. </p>
<p>The Instruction Pointer is part of <em>Memory</em>. (Note: Normally the <strong>Instruction Pointer</strong> will be a “special register” in a CPU core, but here we will simplify the concepts and assume all data (registers included) are part of “Memory”. It will simplify the definition of “<strong>State</strong>”, which is all the referenced memory values in a point of time)</p>
</li>
<li><p><strong>Jump</strong> - Once you have an ordered number of steps and an <em>Instruction Pointer</em>, you can apply the “<strong>store</strong>” instruction to alter the value of the Instruction Pointer itself. We will call this specific use of the <em>store instruction</em> with a new name: <strong>Jump</strong>. We use a new name because is easier to think about it as a new concept. By altering the instruction pointer we’re instructing the agent to “go to step x“.</p></li>
<li>
<p><strong>Infinite Iteration</strong>: By <strong><em>jumping back,</em></strong> now you can make the agent “repeat” a certain number of steps. At this point we have <strong>infinite Iteration.</strong></p>
<pre><code class="prettyprint"> 1. mov 1000 m[30]
2. sub m[30] 1
3. jmp-to 2 // infinite loop
</code></pre>
</li>
<li><p><strong>Conditional</strong> - Conditional execution of instructions. With the “conditional” clause, you can conditionally execute one of several instructions based on the current state (which can be set with a previous instruction). </p></li>
<li>
<p><strong>Proper Iteration</strong>: Now with the <strong>conditional</strong> clause, we can escape the infinite loop of the <strong>jump back</strong> instruction. We have now a <strong>conditional loop</strong> and then <strong>proper Iteration</strong></p>
<pre><code class="prettyprint">1. mov 1000 m[30]
2. sub m[30] 1
3. (if not-zero) jump 2 // jump only if the previous
// sub instruction did not result in 0
// this loop will be repeated 1000 times
// here we have proper ***iteration***, a conditional loop.
</code></pre>
</li>
<li>
<p><strong>Naming</strong>: giving names to a specific memory location holding data or holding a <em>step</em>. This is just a “convenience” to have. We do not add any new instructions by having the capacity to define “names” for memory locations. “Naming” is not a instruction for the agent, it’s just a convenience to us. <em>Naming</em> makes code (at this point) easier to read and easier to change.</p>
<pre><code class="prettyprint"> #define counter m[30] // name a memory location
mov 1000 counter
loop: // name a instruction pointer location
sub counter 1
(if not-zero) jmp-to loop
</code></pre>
</li>
<li>
<p><strong>one-level subroutine</strong>: Suppose there’s a series of steps you need to execute frequently. You can store the steps in a named position in memory and then <em>jump to</em> that position when you need to execute them (call) but at the end of the sequence you’ll need to <em>return</em> to the point of <em>calling</em> to continue execution. With this mechanism, you’re <em>creating new instructions</em> (subroutines) by composing core instructions.</p>
<p><strong>Implementation: (no new concepts required)</strong></p>
<ul>
<li>Store the current Instruction Pointer in a predefined memory position</li>
<li>
<strong>jump</strong> to the subroutine </li>
<li>at the end of the subroutine, you retrieve the Instruction Pointer from the predefined memory location, effectively jumping back to the following instruction of the original <em>call</em>
</li>
</ul>
<p>Problem with the <strong>one-level</strong> implementation: You cannot call another subroutine from a subroutine. If you do, you’ll overwrite the returning address (global variable), so you cannot nest calls.</p>
<p>To have a <strong>better Implementation for subroutines: You need a STACK</strong></p>
</li>
<li><p><strong>STACK</strong>: You define a memory space to work as a “stack”, you can “push” values on the stack, and also “pop” the last “pushed” value. To implement a stack you’ll need a <strong><em>Stack Pointer</em></strong> (similar to the Instruction Pointer) which points to the actual “head” of the stack. When you “push” a value, the stack pointer increments and you store the value. When you “pop”, you get the value at the actual Stack Pointer and then the Stack Pointer is decremented.</p></li>
<li><p><strong>Subroutines</strong> Now that we have a <strong><em>stack</em></strong> we can implement proper subroutines <em>allowing nested calls</em>. The implementation is similar, but instead of storing the Instruction Pointer in a predefined memory position, we “push” the value of the IP in the <em>stack. *At the end of the subroutine, we just “pop” the value from the stack, effectively jumping back to the instruction after the original *call. This implementation, having a “stack” allows calling a subroutine from another subroutine. With this implementation we can create several levels of abstraction when defining *new instructions</em> as subroutines, by using core instructions or another subroutines as building blocks.</p></li>
<li>
<p><strong>Recursion</strong>: What happens when a subroutine calls itself?. This is called “recursion”. The “new” problem with “recursion” (at this point) are the local intermediate results a subroutine can be storing in memory. Since you are calling/reusing the same steps, <strong><em>if</em></strong> the intermediate result are stored in predefined memory locations (global variables) they will be overwritten on a the nested calls.</p>
<p><strong><em>Solution:</em></strong> To allow recursion, subroutines should store local intermediate results in <strong><em>the stack</em></strong>, so on each <em>recursive call</em> (direct or indirect) the intermediate results are stored in different memory locations.</p>
<p>We will call this <strong>“Local State”</strong>: The intermediate values a subroutine uses are stored in a stack, so each execution of the subroutine has it’s own separate memory space, It’s “Local State”. In contrast, values stored at fixed memory locations will be <strong>“Global State”</strong>. </p>
</li>
</ol>
<hr>
<h2 id="conclusion_2">Conclusion: <a class="head_anchor" href="#conclusion_2">#</a>
</h2>
<p>In a Von Neumann Architecture, clearly <strong><em>“iteration”</em></strong> is a simpler/basic concept than <strong><em>“recursion"</em></strong>. We have a form of <strong>Iteration</strong> at level 7, while <strong>recursion</strong> is at level 14 of the concepts hierarchy.</p>
<h3 id="which-one-is-quotbetterquot_3">Which one is “better”? <a class="head_anchor" href="#which-one-is-quotbetterquot_3">#</a>
</h3>
<ul>
<li><p>You should use “iteration” when you are processing simple, sequential data structures, and everywhere a “simple loop” will do.</p></li>
<li><p>You should use “recursion” when you need to process a recursive data structure (I like to call them “Fractal Data Structures”), or when the recursive solution is clearly more “elegant”.</p></li>
</ul>
<p><strong>Advice</strong>: use the best tool for the job, but understand the inner workings of each tool in order to choose wisely.</p>
<p>Finally, note that you have plenty of opportunities to use recursion. You have recursive data structures everywhere, you’re looking at one now: parts of the DOM supporting what you are reading are a RDS, a JSON expression is a RDS, the hierarchical file system in your computer is a RDS, i.e: you have a root directory, containing files and directories, every directory containing files and directories, every one of those directories containing files and directories…</p>
tag:luciotato.svbtle.com,2014:Post/adding-a-new-dimension-to-source-code2014-08-15T11:17:31-07:002014-08-15T11:17:31-07:00Adding a new dimension to source code. Literally.<p>Note: <em>I could have titled this “Curly braces considered harmful”, but titling like that is now considered harmful</em> </p>
<h3 id="unidimensional-source-code_3">Unidimensional source code <a class="head_anchor" href="#unidimensional-source-code_3">#</a>
</h3>
<p>Source code for the most popular programming languages is unidimensional. Just a unidimensional stream of unicode points. This is an artifact if you like of the Turing machine model, or, if you prefer, it is related to the fact that programming languages are analyzed with the same tools of <em>natural</em> languages, and all <em>natural</em> languages, being “spoken”, are constrained by its transmission medium to be a unidimensional stream of sounds and silences. On the other side, computer languages, are rarely “spoken”, so they’re not naturally constrained to a unidimensional stream. </p>
<p>Let’s talk about C. For the C compiler, source is a stream of chars. A c compiler can compile a 100kb source written on one line without line breaks. (Javascript engines do this thousands of times per minute, when somebody visits a page with a minified source). But nobody writes C (or javascript) programs in a single line without line breaks. Also we don’t just add line breaks, we properly indent after “{” and de-indent before “}”.</p>
<p>For the compiler, the source code is a <em>unidimensional</em> stream of chars. Whitespace and line-breaks are ignored. On the other hand, the programmer sees the source code as a <em>bidimensional</em> construction with lines and columns, and withespace and indent are fundamental for code readability.</p>
<p>Proper indent is so important for the programmer that looking at code without proper indentation is like staring a picture frame hanging crooked, and trying to resist fixing it.</p>
<p>This different “vision” between the compiler and the programmer creates a hidden source of big problems. The <a href="https://blog.codecentric.de/en/2014/02/curly-braces/">Apple SSL Bug</a> this year is directly related to this difference in “parsing” from the compiler and the programmer mind. This kind of bug can only slip because the unidimensional/bidimensional mismatch. You can make the same mistake of “pasting twice” the “goto fail;” statement, but fi you do it in Python or LiteScript it will be just a extra ignored statement, instead of a catastrophic bug lurking hidden in the indentation. In Python or LiteScript the blocks you see is also what the compiler sees. </p>
<h3 id="a-new-dimension-in-the-compiler-adds-benefits_3">A new dimension in the compiler adds benefits <a class="head_anchor" href="#a-new-dimension-in-the-compiler-adds-benefits_3">#</a>
</h3>
<p>I believe that a choosing to use indentation for blocks, aka the <a href="http://en.wikipedia.org/wiki/Off-side_rule">Off-side rule</a> is not only a “style” choice for a modern language, it also helps to avoid a large source of subtle, potentially highly problematic bugs.</p>
tag:luciotato.svbtle.com,2014:Post/javascript-untangled2014-07-01T15:34:05-07:002014-07-01T15:34:05-07:00Javascript, untangled<h3 id="background_3">Background <a class="head_anchor" href="#background_3">#</a>
</h3>
<p><em>I’m working on LiteScript, a compile-to-js-language, based in Javascript design (the good parts). LiteScript is also a compile-to-C-language. In order to compile to fast C, it is required to untangle some JS concepts and limit some JS dynamic features</em></p>
<h2 id="untangling-javascript_2">Untangling Javascript <a class="head_anchor" href="#untangling-javascript_2">#</a>
</h2>
<p>Javascript is extremely powerful, and this power allows a programmer to write very clever code, and also shoot herself in the foot in very imaginative ways. </p>
<h2 id="classes-are-functions-and-functions-are-class_2">Classes are Functions, and Functions are Classes <a class="head_anchor" href="#classes-are-functions-and-functions-are-class_2">#</a>
</h2>
<p>In JS a “class” is simply a Function and every Function is a class. This is the first concept to untangle.<br>
In LiteScript, a “Class” is a type of Object, different from a “Function”.</p>
<p><u>JS Function</u>: Object containing executable code. <br>
Functions objects have properties: <em>name, prototype, length</em>.<br>
Functions objects have several methods: <em>apply, call, bind, toString, etc.</em></p>
<p><u>JS Class</u>: see Function.</p>
<p><u>LiteScript Function</u>: executable code, Function objects have no properties, and have two methods: <em>apply</em> and <em>call</em></p>
<p><u>LiteScript Class</u>: model for instances. Class objects have two properties: <em>name</em> and <em>prototype</em>.</p>
<p>We’re simply untangling the two concepts, but keeping JS design. Since we have now a differentiated type “Class”, we moved the properties “name” and “prototype” to the new type.</p>
<p>In JS, the Function-Class is used as the instance initialization (the code initializing the instance property values). In LS, we separate the instance initialization as the class <em>constructor</em>.</p>
<h2 id="to-new-or-not-to-new_2">to new or not to new <a class="head_anchor" href="#to-new-or-not-to-new_2">#</a>
</h2>
<p>In JS you may call a function with “new” or you may not. Sometimes, if the function is mainly a class, the function will take care of this and will create a instance for you (by calling itself with new), sometimes it will not. There are some core JS classes which do not respect this “initialize instance” model, most notably the “Error” Function-Class.</p>
<p>in LiteScript (if you want to compile-to-C later) the only way to create a instance is to use “new” with a Class, also, all core classes respect the “initialize provided instance” model. Moreover: the instance initialization function do not return a value, so it cannot return a different “this” than the provided one.</p>
<h2 id="untangling-objects-and-dictionaries_2">Untangling Objects and Dictionaries <a class="head_anchor" href="#untangling-objects-and-dictionaries_2">#</a>
</h2>
<p>This is one of the most powerful features of JS. JS is self-reflective by default. All Objects are really “bags of dynamic properties”. This is also one of the reasons why normal JS code is slow compared to compiled code, despite great advances of JS engines like V8.</p>
<p>Many JS programs use object as “Dictionaries”, to have fast access to a name:value pair. </p>
<p>In the EcmaScript6 specification, a new concept “Map” is incorporated to JS. From the Map’s viewpoint, a Object is just a Map string=>any</p>
<h2 id="litescript-objects-and-maps_2">Litescript: Objects and Maps <a class="head_anchor" href="#litescript-objects-and-maps_2">#</a>
</h2>
<p>in LiteScript, since we want to compile-to-C, we need to untangle Map and Object.</p>
<p><u>JS Object</u>: bag of dynamic properties. You can access properties with the <em>Property Access Operator</em>, a dot. You can add or delete properties at runtime. </p>
<h3 id="example-of-the-propertyaccess-operator_3">Example of the PropertyAccess operator: <a class="head_anchor" href="#example-of-the-propertyaccess-operator_3">#</a>
</h3>
<pre><code class="prettyprint">obj.someProp.anotherSubProp
</code></pre>
<p><u>JS Map</u> (ES6): bag of dynamic properties.</p>
<p><u>LiteScript Object</u>: instance of a Class. It has a Predefined list of properties. You can access properties with the <em>Property Access Operator</em>, a dot. You can not add new properties at runtime.</p>
<p><u>LiteScript Map</u>: bag of dynamic properties. a Dictionary.</p>
<p>So in LiteScript, you use objects as you define them in Class declarations, and, if you need a “Dictionary”, you use a Map. In order to rewrite JS code in LiteScript, you need to use defined classes instead of patched Objects, and you can’t rely on being able to add or remove new Object properties at runtime. Normally you have to declare and extend classes instead of add or remove properties from Objects.</p>
<h2 id="performance-gains_2">Performance gains <a class="head_anchor" href="#performance-gains_2">#</a>
</h2>
<p>The LiteScript compiler is written in LiteScript. Today, at v0.8.5, the LiteScript compiler can compile itself to-js code and also to-c code.</p>
<p>LiteScript compiler can be compiled to-js in order to execute it under node.js or the browser. LiteScript compiler can be compiled to-c in order to execute it as a standalone executable. When compiled-to-c, LiteScript compiler can self-compile 5x-7x faster than the js version of the same source.</p>
<h2 id="conclusion_2">Conclusion <a class="head_anchor" href="#conclusion_2">#</a>
</h2>
<p>Untangling concepts, incorporating “Class” and limiting “Object”, we’re able to have a language, LiteScript, which is heavily inspired by Javascript, but which can be compiled-to-C when a better performance is required.</p>
<h2 id="status_2">Status <a class="head_anchor" href="#status_2">#</a>
</h2>
<p>LiteScript is beta, and compile-to-C is in alpha stage. Hackers help is required and will be very well received. <a href="http://github.com/luciotato/litescript">http://github.com/luciotato/litescript</a></p>
tag:luciotato.svbtle.com,2014:Post/keep-your-mind-at-full-speed-avoid-branch-mispredictions2014-03-07T13:01:42-08:002014-03-07T13:01:42-08:00Keep your coder's mind at full speed: avoid mental branch mispredictions<h2 id="brains-and-cpus_2">Brains and CPUs <a class="head_anchor" href="#brains-and-cpus_2">#</a>
</h2>
<p>One can make an analogy of the human brain and a CPU, but<br>
never is the analogy more valid than in the case of a programmer<br>
<em>reading</em> source code.</p>
<h2 id="the-coder39s-mind_2">The coder’s mind <a class="head_anchor" href="#the-coder39s-mind_2">#</a>
</h2>
<p>When reading source code, trying to understand what the code does,<br>
the mind of a trained programmer works much like a CPU.</p>
<p>We’re “following” (executing) the source code in our minds, <br>
trying to determine what the program does.</p>
<p><em>..then calls this function, stores result here, if it’s less than 10, then it…</em></p>
<h2 id="branch-misprediction_2">Branch Misprediction <a class="head_anchor" href="#branch-misprediction_2">#</a>
</h2>
<p>Do you know what a “branch misprediction” is ?</p>
<p>Branch misprediction is an interesting artifact of CPU’s execution, <br>
since it effects can “bubble” up to high-level languages.</p>
<p>They say “A picture is worth a thousand words”, well this explanation is illustrated with a picture, and as today it seems to worth more than ten thousands upvotes. </p>
<p>Please <em>go now</em> and read <a href="http://stackoverflow.com/questions/11227809/why-is-processing-a-sorted-array-faster-than-an-unsorted-array/11227902#11227902">this fantastic answer</a> <br>
at StackOverflow. </p>
<h2 id="mbm-mental-branch-misprediction_2">MBM: Mental Branch Misprediction <a class="head_anchor" href="#mbm-mental-branch-misprediction_2">#</a>
</h2>
<p>Now, merging both concepts, a <strong>Mental Branch Misprediction</strong><br>
is what occurs in the coder’s mind when the source code language we’re reading, has some specific constructions causing our minds to “mispredict” execution, and lose our train of thought.</p>
<p>An example of this kind of syntax is the “if modifier”/“if postfix form” <br>
of Ruby & also CoffeeScript (very nice languages)</p>
<p>Here’s a example from CoffeeScript main page:</p>
<pre><code class="prettyprint">number = 42
opposite = true
# Conditions:
number = -42 if opposite
</code></pre>
<p><em>… ok, number=42, opposite=true, now number= - 42… WAIT!… only IF “opposite” then number = - 42…</em></p>
<p>The “WAIT” was branch misprediction on your brain, you had to stop, pull back the train, and parse again.</p>
<p>It was a simple statement, but the complex the code, the more to backtrack. Read the following code:</p>
<pre><code class="prettyprint">number = 42
opposite = true
number = complexFunction.call(obj, oldValue, oldValue+100, baseValue*getFactor()) unless opposite
</code></pre>
<p>From this we can derive a simple rule to avoid mental branch misprediction: all conditionals evaluations should precede conditionally executed statements.</p>
<p>JavaScript (another wonderful language) does not suffer from this, <br>
but it presents a very complex branch prediction cases when you use async callbacks and closures.</p>
<p>Example: (node.js)</p>
<pre><code class="prettyprint">fs.readFile('test', function(err,data){
console.log(data.toString());
if (data.length>1000){
console.log('more than a thousand chars')
};
});
console.log('data read started');
</code></pre>
<p>Again a very simple program, but, follow me while we try to use the tracks junction analogy for this. Suppose the the train is the execution thread:</p>
<blockquote>
<p>The train passes by the junction and go straight saying “read this file please”. <em>At a future time</em>, the train <em>magically reappears running at full speed</em>, but now in the diverging track -just after the junction-, then follows this short track, and disappears to nowhere at the end of it.</p>
</blockquote>
<p>That was just a funny example. Async is really great, and the perfect tool for a myriad of cases, but sometimes you do not want or need async, and a callback only adds a magic future branch to the source code, and trains appearing and disappearing to nowhere. </p>
<p>It can be even worst, when enough async callbacks accumulate you get <br>
the “pyramid of doom” and end up in “callback hell”.</p>
<p>So: <strong>“async is really good”, but not all the time</strong></p>
<p>I love to code, I’ve been programming for a lot of years, and I’ve reached a stage where I really appreciate simplicity, and know how hard is to achieve it. (this blog platform, svbtle, is a good example of “hard to achieve simplicity”)</p>
<p>I am designing a language: <a href="https://github.com/luciotato/LiteScript">LiteScript</a>, -while coding a PEG based compiler/transpiler for it-. One of the design objectives is the kind of simplicity that lets a coder’s mind flow.</p>
<p>The previous async example can be made much more readable<br>
-without losing the async advantages- by using ES6 generators and LiteScript’s “yield until”:</p>
<p>For example, in the nice function below, the callback magic junction is gone and your train of thought can go at full speed.</p>
<pre><code class="prettyprint">nice function sequentialRead
console.log('data read started');
var data = yield until fs.readFile('test')
print data.toString()
if data.length>1000, print 'more than a thousand chars'
</code></pre>
<p>Please check <a href="https://github.com/luciotato/LiteScript">LiteScript</a>. It is open source, brand new, still in beta, and I’ll appreciate collaborations.</p>
<p>A teaser: <em>write the following in pure js (node)</em></p>
<h5 id="get-googlecom-ips-then-reverse-dns-in-paralle_5">get google.com IPs, then reverse DNS (in parallel) <a class="head_anchor" href="#get-googlecom-ips-then-reverse-dns-in-paralle_5">#</a>
</h5>
<p>LiteScript code:</p>
<pre><code class="prettyprint">global import dns, nicegen
nice function resolveAndParallelReverse
try
var domain = "google.com"
var addresses:array = yield until dns.resolve domain
var results = yield parallel map addresses dns.reverse
for each index,addr in addresses
print "#{addr} reverse: #{results[index]}"
catch err
print "caught:", err.stack
end nice function
</code></pre>