Прекрасная вводная статья в сложность алгоритмов. http://discrete.gr/complexity/

Отличный туториал по haskell + visualization + opengl http://goo.gl/r5SVj

GC в рантайме D говно via → http://thedeemon.livejournal.com/49421.html

Фичи Unreal Engine 4 http://youtu.be/MOvfn1p92_8

Тупой вопрос: почему адресация std::vector начинается с 0, а не с 1? Чтобы проще было переписывать сишный код на STL?

Очень вкучный разбор кода двига doom3 http://fabiensanglard.net/doom3/index.php

Чят, какую подсветку для текущего и outer sexp-ов сделать? Черный и синий как-то не особо смотрятся: http://ompldr.org/vZTR4eg

Hash Functions for C++ Unordered Containers http://marknelson.us/2011/09/03/hash-fun.....ontainers/

Раз уж на жуйце неделя GC, то реквестирую советов: Допустим, я реализую. Язык с GC. Что лучше: 1. Пожрать говна^W^W сделать GC самому (по наитию) и потом ужаснуться от результата и перейти к п. 2. 2. Почитать хороших вайтпапиров и реализовать какой-нибудь из описанных алгоритмов. ?

Бесплатная раздача случайных чисел. ANU Quantum Random Numbers Server http://150.203.48.55/index.php

вот код из #1899432 Предлагайте ваши варианты по оптимизации. ----------------------------------------- void calcParticles() { #ifdef USE_OPENMP #pragma omp parallel for #endif for (int i = 0; i < pVecSz; i++) { Particle &p = particleVec[i]; float sqrs = sqrt((X-p.x)*(X-p.x)+(Y-p.y)*(Y-p.y)+(Z-p.z)*(Z-p.z) ); float f = G*((p.M*M)/sqrt(rs)); float f = G*((p.M*M)/1.0); float a = f/p.M; float cosx = (X-p.x)/sqrs; float cosy = (Y-p.y)/sqrs; float cosz = (Z-p.z)/sqrs; float ax = a*cosx; float ay = a*cosy; float az = a*cosz; p.vx += ax*1/invFPS; p.vy += ay*1/invFPS; p.vz += az*1/invFPS; p.x += p.vx; p.y += p.vy; p.z += p.vz; } } ------------------------------------------ Сам думаю: 1. Вынести за пределы цикла: float f = G*((p.M*M)/1.0); float a = f/p.M; 2. Заюзать pthreads (вдруг полущ будет) 3. Заюзать SSE3 для извлечения квадратного корня и подсчетса направляющих косинусов.

Чят, а у core i5 один FPU или по одному на каждое ядро? Запускаю быдлокод с openmp, который молотит массив. Прироста в производительности никакого.

Туториал по sequent calculus http://logitext.ezyang.scripts.mit.edu/l.....i/tutorial

/MinGW, MSVC 10 and Intel C++ compilers are supported but not tested./ Это как вообще?

Создателям мануалов, которые делают примеры кода в картинках нужно гореть в аду. ispired by http://sourceware.org/systemtap/tutorial.....ction.html

Хозяйке на заметку: Пач against 2.6.34.7 чтобы создавалось устройство /dev/one, которое возвращает 0xFF при чтении из него. diff --git a/drivers/char/mem.c b/drivers/char/mem.c index 53dd7d0..21590ae 100644 --- a/drivers/char/mem.c +++ b/drivers/char/mem.c @@ -789,6 +789,24 @@ static ssize_t read_zero(struct file *file, char __user *buf, return written ? written : -EFAULT; } +static ssize_t read_one(struct file * file, char __user * buf, + size_t count, loff_t *ppos) +{ + size_t written; + unsigned long unwritten; + static int one = ~0; + + for (written = 0; written < count; written++) { + unwritten = copy_to_user(&buf[written], &one, 1); + if (unwritten) + break; + cond_resched(); + } + + return written ? written : -EFAULT; +} + + static int mmap_zero(struct file *file, struct vm_area_struct *vma) { #ifndef CONFIG_MMU @@ -860,6 +878,10 @@ static int open_port(struct inode * inode, struct file * filp) #define open_mem open_port #define open_kmem open_mem #define open_oldmem open_mem +#define one_lseek null_lseek +#define write_one write_null +#define mmap_one mmap_zero + #ifndef ARCH_HAS_DEV_MEM static const struct file_operations mem_fops = { @@ -930,6 +952,13 @@ static const struct file_operations oldmem_fops = { }; #endif +static const struct file_operations one_fops = { + .llseek = one_lseek, + .read = read_one, + .write = write_one, + .mmap = mmap_one, +}; + static ssize_t kmsg_write(struct file *file, const char __user *buf, size_t count, loff_t *ppos) { @@ -977,6 +1006,7 @@ static const struct memdev { #ifdef CONFIG_CRASH_DUMP [12] = { "oldmem", 0, &oldmem_fops, NULL }, #endif + [13] = { "one", 0, &one_fops, NULL }, }; static int memory_open(struct inode *inode, struct file *filp)

О, cuda научилась LLVM-у. Будет больше cuda-поделок на хаскеле.

Чят, хочу знать насколько использование байткода (не JIT) в интерпретаторе заместо тупого парсинга дает выигрыш в производительности? Есть ли истории успеха?

The Biggest Changes in C++11 (and Why You Should Care) http://www.softwarequalityconnection.com.....ould-care/

*video via comp.lang.lisp: The Remote Agent Experiment: Debugging Code from 60 Million Miles Away http://youtu.be/_gZK0tW8EhQ