Pull to refresh

Проблемы разработки реально быстрого ПО в наше время

Reading time 2 min
Views 963
Дрова пилятся, пилы совершенствуются, доски всё длинные и длинные,
а вот скорость наших программ не сопоставляется с размером этих досок…
Как-то задумал я раз в свои 18 писать компилятор большой-широкий, идей для него выписал целый блокнот.
Так и умер он за вечной оптимизацией собственного кода… =)

Я решил представить общественности несколько своих идей
и если что-то их заинтересовало прошу связаться со мной для определения подальшей деятельности.
Проще говоря — я искаю друзей, для разработки само-оптимизирующегося компилятора основаного на датамайнинге и генетических алгоритмах + много весёлых вкусностей стандартной библиотеки.

Вот так вот начинается моё небольшое предисловие первого поста на хабре.
Данная отписка не требует полного раскрытия темы, а просто объясняет мои позиции
по-поводу существующих систем компиляции и обработки кода которые я использую в своих разработках.

Ну начнём…

Все мы знаем что потоки это хорошо: они позволяют нам «распаралеливать» наши программы
и использовать их на многоядерных архитектурах «на 100%»
Часто люди думают: «Оооо может лучше я объявлю несколько потоков для обработки этого цикла,
а может быть он исполниться когда-то на 64 ядерной машине»
И не понимают на сколько парадоксально это звучит.

Во-первых: уважайте наших дедов-коддеров, услышав подобное, у них бы случился повторный инфаркт.
Зачем объявлять статическое количество структур для обработки динамического количества других структур.

Во-вторых: а выгодно ли это? вот представим 16 потоков на 4-ёх ядерном процессоре — стандартная ситуация. Не так ли? получается что мы делим всё на 16 мелких частей и допишем перед ними львиную долю повторяющегося threat api, а не проще будет объявить всего лишь 4 потока и выиграть в производительности на этом за счёт уменьшения времени объявления инициализации и деструкции потоков…

В-третих: Кто сказал что распределение задач на все threat'ы будет ити поровну. И не получится что 3 потока ждут результата одного.

В-четвёртых: memory corrupt, memory poisoning, dead locks and so on… Все пользователи OpenMP и
Pthreats встречались с подобными проблемами. Хотя они были уже давно решены с помощью erlang'a

В-пятых: CUDA, OpenCL, DirectCompute Все вспомнили что видеокарта єто процессор…
Не много же времени прошло. А смысл этих разработок? Увеличить быстродействие и т.д.
Так вот личьный дамп старого доброго фотошопа СS4 показывает что 40-60% времени может
расходоваться на «смену режимов ядра CUDA» как это назвали разрабы Nvidia.
Люди забыли что у шейдерного конвейера ограниченная точность и набор комманд.
Вот ему и приходится иногда сбрасывать часть кода на выполнение в процессор.

В-шестых: сколько расширений для прорисовки графики мы знаем?.. да полным-полно.
А сколько из них используется в Cuda?

Да может вы и продвинутый мего-коддер, ни точто я — простой студент.
И для вас игра потоков (и дед-локов) вполне привычна последние года 3.
Ну шарите (допустим) вы… Шарите…
Только ли стоит игра свеч? На сколько сложнее дебаг?
На сколько сложное обеспечение синхронности/асинхронности потоков?
Или же вы не заморачивайте себе голову?.. Работает, слово закажчика — закон, и т.д.

Вот я и принялся разгребать это безобразие. Весело не корыстно и безрассудно…
Нужно же автоматизировать/оптимизировать это.

Продолжение следует, может этого и мало, но по-делу…
Во втором посте я расскажу что же я хочу предпринять.
Надеюсь на понимание и мягкую критику «по-теме».

Спасибо за внимание.
Tags:
Hubs:
-9
Comments 25
Comments Comments 25

Articles