wizzard: (Default)
2013-10-02 05:23 pm

я понял

а вы когда-нибудь задумывались, что обфускация кода в пределе эквивалентна гомоморфному шифрованию?

то-то мне исторически все время казалось, что в пейперах какие-то очень похожие концепции проскакивают...
wizzard: (Default)
2013-09-17 01:34 pm

Про CLR security

...aka "что удерживает меня от перехода с Microsoft'овского стэка на что-то другое"

Пост родился из продолжительной дискуссии с _sorcerer на тему "а чем NaCl хуже?", которая продолжилась в духе "но лучше ведь сделать нельзя", а чтобы не шерстить свои заметки по второму кругу - решил вынести ссылки из коммента в пост.

итак. http://www.cs.virginia.edu/~nrp3d/papers/computers_and_security-net-java.pdf старый, но актуальный обзор
http://www.onjava.com/pub/a/onjava/2004/01/28/javavsdotnet.html?page=4 а вот тут наглядно показана разница между подходами (в одном случае проверяется формальная модель, в другом - валидация отдана на откуп программисту, что и приводит к последствиям описанным в предыдущем обзоре)

http://research.microsoft.com/en-us/um/people/fournet/pwp/default.htm история поиска проблем в секьюрити-модели дотнета и разработки диагностических тулзов (понятно, что можно руками нарисовать на методе formatDisk, что его могут вызывать все, но это можно статически обнаружить, что в Джаве невозможно)

http://msdn.microsoft.com/en-us/magazine/ee677170.aspx к чему в итоге пришли (не стоит читать раньше других ссылок, т.к. будет непонятна терминология)

http://people.csail.mit.edu/jeanyang/papers/pldi117-yang.pdf расширение идей до целой ОС

читать по порядку, потом читать референсы, тоже по порядку. да, читать здесь МНОГО.

при этом у меня так и остался неотвеченный вопрос - почему кроме MS Research никто этим не занимается? ну или может занимается, так где же хотя бы пейперы?
wizzard: (Default)
2013-02-07 05:15 am

Premature optimization

Here are the things that continue to bite me, so I'll try to write them down, maybe somebody else will learn a bit too.

1. At some point, all increasingly sophisticated algorithms give diminishing returns.

This is the same as with compression. There are only so much kinds of compressible data - most kinds of data are incompressible, it's just that we mostly happen to work with compressible ones.

In general, algorithms can't be optimized, but you can pick some corner cases and optimize for them.

2. Today, every machine is a multiprocessor, supercomputer machine. In this setting, you're not ALU-bound, you're memory bound. And latency-bound (remember Amdahl's law?).

Hardware is getting cheaper. But your time is not. And latencies are not.

So, one should always optimize for latency, and sometimes for memory bandwidth, but not for ALU throughput. This means optimizing for data layout. Forget algorithms. Layout is everything. Seek-friendly, cache-friendly, etc etc etc.

You can afford 1 HDD seek per frame, and about 100-200 SSD seeks. SSD's rock!
And, while you can process up to 100M floats per frame (on todays' desktop CPU), you can only really reach 100-150K distinct memory locations (approx.)

Basically, you can make only so much "decisions" per frame. SIMD, VLIW are all cool and nice, but it does not mean you can do "more". It only means you can work with bigger entities, that's all. Vectors instead of bytes. But not "more bytes".

One thing that makes GPUs so fast is that they can nicely mask these latencies.. but only as long as their beefy memory controller can keep up dispatching bytes to 'threads'. So, never, ever buy GPUs with 128 (or even 64) bit memory bus.

3. When buying hardware, it's always better to buy top previous generation models instead of middle-tier current-gen. GPUs are the most notable example, but it's the same with CPUs. Just look at cpubenchmark.net and so on. The only exception currently is power efficiency.

But, hey, if you're concerned about power, you're probably buying the assembled device (laptop etc) anyway, so just look at the reviews.

EDIT: Mobile CPUs are quickly catching up with desktop ones. Including the latencies. But the throughput is severely capped there - because of power consumption. In some sense, mobile devices are more "balanced" than desktops now. And downscaling does not always work, because screens are basically the same resolution on computers and phones, just the DPI is different.

EDIT2: IMHO, latency (and security) are the real sources of composability and abstraction limits. When things stacked on each other suddenly start to run slow, the problem is not solvable neither by hardware nor by adding an abstraction layer. Same applies to the situation when the system just goes haywire in an unpredictable way.