Skip to content

Instantly share code, notes, and snippets.

View nyukhalov's full-sized avatar
🚀
to infinity and beyond

Roman Niukhalov nyukhalov

🚀
to infinity and beyond
View GitHub Profile
@hellerbarde
hellerbarde / latency.markdown
Created May 31, 2012 13:16 — forked from jboner/latency.txt
Latency numbers every programmer should know

Latency numbers every programmer should know

L1 cache reference ......................... 0.5 ns
Branch mispredict ............................ 5 ns
L2 cache reference ........................... 7 ns
Mutex lock/unlock ........................... 25 ns
Main memory reference ...................... 100 ns             
Compress 1K bytes with Zippy ............. 3,000 ns  =   3 µs
Send 2K bytes over 1 Gbps network ....... 20,000 ns  =  20 µs
SSD random read ........................ 150,000 ns  = 150 µs

Read 1 MB sequentially from memory ..... 250,000 ns = 250 µs

@jboner
jboner / latency.txt
Last active May 1, 2024 14:21
Latency Numbers Every Programmer Should Know
Latency Comparison Numbers (~2012)
----------------------------------
L1 cache reference 0.5 ns
Branch mispredict 5 ns
L2 cache reference 7 ns 14x L1 cache
Mutex lock/unlock 25 ns
Main memory reference 100 ns 20x L2 cache, 200x L1 cache
Compress 1K bytes with Zippy 3,000 ns 3 us
Send 1K bytes over 1 Gbps network 10,000 ns 10 us
Read 4K randomly from SSD* 150,000 ns 150 us ~1GB/sec SSD
@Chaser324
Chaser324 / GitHub-Forking.md
Last active April 28, 2024 18:27
GitHub Standard Fork & Pull Request Workflow

Whether you're trying to give back to the open source community or collaborating on your own projects, knowing how to properly fork and generate pull requests is essential. Unfortunately, it's quite easy to make mistakes or not know what you should do when you're initially learning the process. I know that I certainly had considerable initial trouble with it, and I found a lot of the information on GitHub and around the internet to be rather piecemeal and incomplete - part of the process described here, another there, common hangups in a different place, and so on.

In an attempt to coallate this information for myself and others, this short tutorial is what I've found to be fairly standard procedure for creating a fork, doing your work, issuing a pull request, and merging that pull request back into the original project.

Creating a Fork

Just head over to the GitHub page and click the "Fork" button. It's just that simple. Once you've done that, you can use your favorite git client to clone your repo or j

@iros
iros / API.md
Created August 22, 2012 14:42
Documenting your REST API

Title

<Additional information about your API call. Try to use verbs that match both request type (fetching vs modifying) and plurality (one vs multiple).>

  • URL

    <The URL Structure (path only, no root url)>

  • Method:

@beci
beci / gcc 5 on ubuntu 14.04
Created October 15, 2015 07:18
use gcc 5.x on ubuntu 14.04
sudo add-apt-repository ppa:ubuntu-toolchain-r/test
sudo apt-get update
sudo apt-get install gcc-5 g++-5
sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-5 60 --slave /usr/bin/g++ g++ /usr/bin/g++-5
@lambdalisue
lambdalisue / README.markdown
Last active October 28, 2023 18:12
n-dimensional hyperplane (line for 2D, plane for 3D) fitting via singular value decomposition method

n-dimensional hyperplane (line for 2D, plane for 3D) fitting via singular value decomposition method

Screenshot

@viktorklang
viktorklang / Future-retry.scala
Last active July 23, 2023 23:48
Asynchronous retry for Future in Scala
import scala.concurrent.duration._
import scala.concurrent.ExecutionContext
import scala.concurrent.Future
import akka.pattern.after
import akka.actor.Scheduler
/**
* Given an operation that produces a T, returns a Future containing the result of T, unless an exception is thrown,
* in which case the operation will be retried after _delay_ time, if there are more possible retries, which is configured through
* the _retries_ parameter. If the operation does not succeed and there is no retries left, the resulting Future will contain the last failure.
@noelwelsh
noelwelsh / loop.scala
Created October 15, 2015 16:18
Example of monadic loop using the State monad in Cats
import cats.{Id,Monad}
import cats.state.State
import cats.std.function._
import scala.language.higherKinds._
// Call Example.example.run to see the example running
object Example {
type MyState[A] = State[Int, A]
@danswick
danswick / README.md
Last active December 26, 2022 04:05
Indoor map example

Using a hypothetical museum floorplan to demonstrate hover and click interactivity, as well as fitBounds.

@RayRoestenburg
RayRoestenburg / firstSucceededOf.scala
Last active May 20, 2021 21:45
firstSucceededOf, returns a future containing the first successful result or contains the last failure if all futures have failed. What's wrong with it?
import scala.concurrent._
import scala.concurrent.ExecutionContext.Implicits.global
import scala.util._
import java.util.concurrent.atomic.AtomicInteger
def firstSucceededOf[T](futures: TraversableOnce[Future[T]])(implicit executor: ExecutionContext): Future[T] = {
val p = Promise[T]()
val size = futures.size
val failureCount = new AtomicInteger(0)