fr33m0nk

package single_routine

import (
	"log"
	"sync"
	"sync/atomic"
)

type deferred[B any] struct {
	b   B

fr33m0nk

package concurrent

import (
  "sync/atomic"
)
type Ref[A any] interface {
	Get() A
	Set(a A)
	UpdateAndGet(f func (A) (A)) A
	GetAndSet(a A) A

fr33m0nk

Foreward

This document was originally written several years ago. At the time I was working as an execution core verification engineer at Arm. The following points are coloured heavily by working in and around the execution cores of various processors. Apply a pinch of salt; points contain varying degrees of opinion.

It is still my opinion that RISC-V could be much better designed; though I will also say that if I was building a 32 or 64-bit CPU today I'd likely implement the architecture to benefit from the existing tooling.

Mostly based upon the RISC-V ISA spec v2.0. Some updates have been made for v2.2

Original Foreword: Some Opinion

The RISC-V ISA has pursued minimalism to a fault. There is a large emphasis on minimizing instruction count, normalizing encoding, etc. This pursuit of minimalism has resulted in false orthogonalities (such as reusing the same instruction for branches, calls and returns) and a requirement for superfluous instructions which impacts code density both in terms of size and

fr33m0nk

My notes from attempting to read the Dynamo paper ( Dynamo: Amazon's Highly Available Key-value Store)

1. Introduction
2. Background
3. Related work
4. System Architecture
5. Implementation
6. Experiences and Lessons learned
7. Conclusions

Buzzwords: Key-Value store, primary key, eventual consistency, CAP theorem, hinted handoff, consistent hashing, virtual nodes.

fr33m0nk

• Write the test first -> Try and run the test -> Write the minimal amount of code for the test to run and check the failing test output -> Write enough code to make it pass -> Refactor
• We must not neglect our test code in the refactoring stage
• It is important to question the value of your tests. It should not be a goal to have as many tests as possible, but rather to have as much confidence as possible in your code base. Having too many tests can turn in to a real problem and it just adds more overhead in maintenance. Every test has a cost.
• reflect.DeepEqual - useful for seeing if any two variables are the same. Caveat: It is not type safe. Compiles even if silly comparisons like array == string is done. https://golang.org/pkg/reflect/#DeepEqual

fr33m0nk

Epigrams on Programming

Alan J. Perlis, Yale University

This text has been published in SIGPLAN Notices Vol. 17, No. 9, September 1982, pages 7 - 13. I'm offering it here online until ACM stops me.

The phenomena surrounding computers are diverse and yield a surprisingly rich base for launching metaphors at individual and group activities. Conversely, classical human endeavors provide an inexhaustible source of metaphor for those of us who are in labor within computation. Such relationships between society and device are not new, but the incredible growth of the computer's influence (both real and implied) lends this symbiotic dependency a vitality like a gangly youth growing out of his clothes within an endless puberty.

The epigrams that follow attempt to capture some of the dimensions of this traffic in imagery that sharpens, focuses, clarifies, enlarges and beclouds our view of this most remarkable of all mans' artifacts, the computer.

fr33m0nk

FWIW: I (@Rondy) am not the author of the content presented here, which is an outline from Edmond Lau's book. I've just copy-pasted it from somewhere and saved as a personal gist, before it got popular on newsnews.ycombinator.com. I don't remember where exactly the original source is from and neither could find the author's name, so I cannot give him/her the proper credits.

---

Effective Engineer - Notes

• By Edmond Lau
• Highly Recommended 👍
• http://www.theeffectiveengineer.com/

fr33m0nk

"A little bit of slope makes up for a lot of y-intercept"

01/13/2012. From a lecture by Professor John Ousterhout at Stanford, class CS140

Here's today's thought for the weekend. A little bit of slope makes up for a lot of Y-intercept.

[Laughter]

fr33m0nk

A collection of The Morning Paper posts relating to containers, operating systems etc.

In order of first appearance in The Morning Paper.

• On the duality of operating system structures
• Why threads are a bad idea
• Why events are a bad idea
• Unikernels: library operating systems for the cloud
• The scalable commutativity rule: designing scalable software for multicore processors
• Jitsu: just-in time summoning of unikernels

fr33m0nk

(ns monads)

(defn- ensure-instance [class val constructor]
  (if (instance? class val)
    val
    (constructor val)))

(defprotocol IMonad
  (bind [this f]))