Здравствуйте, Sheridan, Вы писали:

S>Напомню, с чего всё началось. Началось всё с того, что я предположил дальнейший путь повышения производительности софта, в связи с скорым (?) достижением железом потолка, будет прокладываться в сторону распараллеливания.
Тут есть ещё такой момент. Описанный, ЕМНИП, у Кнута.
Возьмём какую-нибудь простую задачку. Например, сортировку массива.
Есть десятки алгоритмов, построенных для однопоточных реализаций. Есть несколько алгоритмов, которые построены для многопоточных.
Возьмём экстремальный пример: предположим, у нас есть неограниченное количество "ядер" — вычислителей, каждый из которых может выполнять простую операцию типа compare-and-swap за одну стадию.
Длина массива — N. За какое минимальное количество стадий мы можем отсортировать массив?
Внезапно выясняется, что у современной математики нет способа решения таких задач. Для небольших количеств ядер (<10) нам известны оптимальные конфигурации процессорной сети — полученные, собственно, прямым перебором.

На Ленте выложили довольно интересную аналитическую статью — http://lenta.ru/articles/2015/05/19/thaw/. Не скажу что лично я с ней полностью согласен, но она интересна тем, что содержит в практически чистом виде одну из основных позиций в ситуации. В частности, думаю, это очень близко к позиции российских властей.

В отличие от привычных обзоров новинок оборудования будет использоваться очень старое железо. Логика в этом есть, так как минимальные требования в играх обычно как раз Intel Pentium 4 3GHz или даже раза в два выше. Чем хуже процессор, тем хуже совместимость с играми и всякими стимами, и тем лучше тест на пригодность полученной системы для людей с образованием кухарки.

Текущее оборудование:

Материнская плата: Asus P5AD2-E Premium
Процессор: Intel Pentium 4 CPU 3.00GHz
Системная память: DDR2 3GiB
Видеокарта: NVIDIA GeForce GTX 660 Ti 2MiB 1344 Cores

Проверка операционной системы:

uname -a
Linux security 3.13.0-49-generic #83-Ubuntu SMP Fri Apr 10 20:14:51 UTC 2015 i686 i686 i686 GNU/Linux

И ещё так:

lsb_release -a
Distributor ID: Ubuntu
Description:    Ubuntu 14.04.2 LTS
Release:        14.04
Codename:       trusty

Процессор более чем десятилетней давности, потому не помешала бы проверка на совместимость.
[code]
lscpu

Про эльфов или 'икспертов'

В последнее время об анализе защищенности исходного кода не написал только ленивый. Оно и понятно, ведь тот парень из Gartner, как предложил рассматривать анализ исходного кода в качестве нового хайпа несколько лет назад, так до сих пор и не дал отмашку на то, чтобы прекратить это делать. А, учитывая текущее направление моей работы (участие в разработке PT Application Inspector, далее AI), и тот факт, что в последнее время годных статей на тему анализа исходного кода в общем-то не было, как-то даже странно, что до сегодняшнего дня в этом блоге не было ни одной грязной подробности на эту животрепещущую тему. Что ж, исправляюсь

Читать дальше

Начинаю описывать концепции Nitra выходящие за пределы парсинга. Начну, пожалуй, с терминологии, чтобы было на что ссылаться в последующих постах.

Буду краток.

HgLab -- написанный на .NET сервер Mercurial с поддержкой Push/Pull, браузер исходников, управлятор группами и пользователями и (в будущем) многое другое интересное (Merge Request'ы, поиск по коду, Issue Tracking, Deployment Tracking).

Сейчас доступна первая альфа, которая уже второй месяц гоняется у меня в команде и догфудится по полной программе.

Наткнулся недавно на youtube на интересный канал. Жанровую принадлежность определить сложно, получается эдакая солянка из "о жизни", "cookbook" и "охота и рыбалка".
Весьма понравилась манера общения Николая Абоимова — остаётся приятное ощущения от монолога/диалога сильного и доброго человека.
Доброта, это вообще такая штука с которой последнее время наблюдается жуткий дефицит.

Для начала небольшое наблюдение. При прочих равных условиях маленькую программу создать обычно легче, чем большую. Однако так же верно, что суммарная сложность частей порой оказывается гораздо выше в собранной единой системе, чем в отдельных её составляющих. Иными словами по мере увеличения размера кода программы сложность создания растёт непропорционально применяемым усилиям.



После начала работ в случае линейной зависимости созданного функционала от затраченных усилий получаем прямую синюю линию. На практике же она часто становится красной линией, которая в конце концов может настолько сильно отдалиться от синей, что усилия на усовершенствование программы становятся неоправданно высоки. В идеале потратив время на создания гибкой архитектуры могли бы сократить издержки при расширении программы, в основном за счёт более быстрого комбинирования уже существующего функционала, смотрим зелёную линию.

Но архитектура это отдельный разговор...