| // Rand fill buffer: 3.894 GiB/s | Instant { tv_sec: 554538, tv_nsec: 411678934 } | Rand buffer beginning: [131, 217, 107, 91, 100, 45, 141, 113, 182, 115] | |
| // Write speed: 7.058 GiB/s | 1.416909244s | Write buffer beginning: [131, 217, 107, 91, 100, 45, 141, 113, 182, 115] | |
| // Read speed: 10.746 GiB/s | 930.555263ms | File beginning: [131, 217, 107, 91, 100, 45, 141, 113, 182, 115] | |
| // Verified 0 bytes look incorrect | 28.545 GiB/s | 350.32772ms | |
| // Hardware: raid-1 two SAMSUNG MZQL23T8HCLS-00A07 | |
| // Capacity: 3.84 Tb | |
| // Form Factor: U.2 | |
| // Seq. Read: 6.333 GiB/s | |
| // Ran. Read: 1000k Iops |
This project is a tiny compiler for a very simple language consisting of boolean expression.
The language has two constants: 1 for true and 0 for false, and 4 logic gates:
! (not), & (and), | (or), and ^ (xor).
It can also use parentheses to manage priorities.
Here is its grammar in BNF format:
expr ::= "0" | "1"
Intel added the Galois Field instruction set (GFNI) extensions to their Sunny Cove and Tremont cores. What’s particularly interesting is that GFNI is the only new SIMD extension that came with SSE and VEX/AVX encodings (in addition to EVEX/AVX512), to allow it to be supported on all future Intel cores, including those which don’t support AVX512 (such as the Atom line, as well as Celeron/Pentium branded “big” cores).
I suspect GFNI was aimed at accelerating SM4 encryption, however, one of the instructions can be used for many other purposes. The extension includes three instructions, but of particular interest here is the Affine Transformation (GF2P8AFFINEQB), aka bit-matrix multiply, instruction.
There have been various articles which discuss out-of-band
| #connect cluster('help.kusto.windows.net').database('Samples') | |
| //Show random storm events | |
| StormEvents | |
| | where isnotempty( BeginLat) and isnotempty( BeginLon) | |
| | project BeginLon, BeginLat, EventType | |
| | take 300 | |
| | render scatterchart with (kind = map) | |
| //Show nearby storm events |
| # Viktor Dukhovni's (@vdukhovni) slow rebase, made faster by bisecting, sort of | |
| # | |
| # fastrebase BRANCH_TO_REBASE ONTO | |
| function fastrebase { | |
| typeset b N | |
| if (($# > 0)) && [[ $1 = -h || $1 = --help ]]; then | |
| printf 'Usage: fastrebase BRANCH_TO_REBASE ONTO_HEAD\n' | |
| printf ' fastrebase # to continue after resolving conflicts\n' | |
| printf '\n\tfastrebase is a shell function that uses the following\n' |
With the addition of ES modules, there's now no fewer than 24 ways to load your JS code: (inline|not inline) x (defer|no defer) x (async|no async) x (type=text/javascript | type=module | nomodule) -- and each of them is subtly different.
This document is a comparison of various ways the <script> tags in HTML are processed depending on the attributes set.
If you ever wondered when to use inline <script async type="module"> and when <script nomodule defer src="...">, you're in the good place!
Note that this article is about <script>s inserted in the HTML; the behavior of <script>s inserted at runtime is slightly different - see Deep dive into the murky waters of script loading by Jake Archibald (2013)
| // You may want to first disable transparent huge pages: | |
| // | |
| // echo never | sudo tee /sys/kernel/mm/transparent_hugepage/enabled | |
| package main | |
| import ( | |
| "flag" | |
| "fmt" | |
| "io/ioutil" |
| WAYLAND_PROTOCOLS=/usr/share/wayland-protocols | |
| # wayland-scanner is a tool which generates C headers and rigging for Wayland | |
| # protocols, which are specified in XML. wlroots requires you to rig these up | |
| # to your build system yourself and provide them in the include path. | |
| xdg-shell-protocol.h: | |
| wayland-scanner server-header \ | |
| $(WAYLAND_PROTOCOLS)/stable/xdg-shell/xdg-shell.xml $@ | |
| xdg-shell-protocol.c: xdg-shell-protocol.h |
