| // A small, and relatively primitive, C-style Brainfuck compiler/interpreter. | |
| // Written by Joe Savage, 2014 | |
| #include <stdlib.h> | |
| #include <unistd.h> | |
| #include <stdio.h> | |
| #include <limits.h> | |
| #define STACK_SIZE 512 | |
| #define DATA_SIZE 65535 |
| *.png | |
| *.gif |
| // Conjugate split-radix FFT inner loop | |
| // Both of these compiled with VC++ 2012, 32-bit, "/O2 /fp:fast". | |
| // NOTE: I also tried clang-cl and it seems to be primarily a VC++ | |
| // problem. (Which doesn't help me much.) | |
| // | |
| // NOTE 2: argh, did the Clang test wrong. It's still primarily a | |
| // VC++ problem, but Clang has a notable slowdown too. Anyway, new | |
| // results generated automatically from a simpler standalone test | |
| // where I can toggle between versions using a single commandline |
| <!doctype html> | |
| <html> | |
| <head> | |
| <meta charset="utf-8"> | |
| </head> | |
| <body> | |
| <script type="application/javascript;version=1.7"> | |
| var worker = new Worker('worker.js'); | |
| var g; |
| ; A minimal Mach-o x64 executable for OS X (also see below Mountain Lion version) | |
| ; | |
| ; $ nasm -f bin -o tiny_hello tiny_hello.s | |
| ; $ chmod +x tiny_hello | |
| ; $ ./tiny_hello | |
| ; Hello World! | |
| ; $ | |
| ; c.f. | |
| ; http://osxbook.com/blog/2009/03/15/crafting-a-tiny-mach-o-executable/ ( the original tiny mach-o executable ) |
| // float->sRGB8 conversions - two variants. | |
| // by Fabian "ryg" Giesen | |
| // | |
| // I hereby place this code in the public domain. | |
| // | |
| // Both variants come with absolute error bounds and a reversibility and monotonicity | |
| // guarantee (see test driver code below). They should pass D3D10 conformance testing | |
| // (not that you can verify this, but still). They are verified against a clean reference | |
| // implementation provided below, and the test driver checks all floats exhaustively. | |
| // |
| Why do compilers even bother with exploiting undefinedness signed overflow? And what are those | |
| mysterious cases where it helps? | |
| A lot of people (myself included) are against transforms that aggressively exploit undefined behavior, but | |
| I think it's useful to know what compiler writers are accomplishing by this. | |
| TL;DR: C doesn't work very well if int!=register width, but (for backwards compat) int is 32-bit on all | |
| major 64-bit targets, and this causes quite hairy problems for code generation and optimization in some | |
| fairly common cases. The signed overflow UB exploitation is an attempt to work around this. |
| /* ======================================================================== | |
| $File: tools/ctime/ctime.c $ | |
| $Date: 2016/05/08 04:16:55PM $ | |
| $Revision: 7 $ | |
| $Creator: Casey Muratori $ | |
| $Notice: | |
| The author of this software MAKES NO WARRANTY as to the RELIABILITY, | |
| SUITABILITY, or USABILITY of this software. USE IT AT YOUR OWN RISK. |
Memory Optimization (Christer Ericson, GDC 2003)
http://realtimecollisiondetection.net/pubs/GDC03_Ericson_Memory_Optimization.ppt
Cache coherency primer (Fabian Giesen)
https://fgiesen.wordpress.com/2014/07/07/cache-coherency/
Code Clinic 2015: How to Write Code the Compiler Can Actually Optimize (Mike Acton)
http://gdcvault.com/play/1021866/Code-Clinic-2015-How-to
Author: https://www.cyanhall.com/
Core Animation's original name is Layer Kit
Core Animation is a compositing engine; its job is to compose different pieces of visual content on the screen, and to do so as fast as possible. The content in question is divided into individual layers stored in a hierarchy known as the layer tree. This tree forms the underpinning for all of UIKit, and for everything that you see on the screen in an iOS application.
In UIView, tasks such as rendering, layout and animation are all managed by a Core Animation class called CALayer. The only major feature of UIView that isn’t handled by CALayer is user interaction.
There are four hierarchies, each performing a different role: