Высокий/низкий уровень, ручное/автоматическое управление

← →
Дмитрий Белькевич (2010-11-10 13:26) [80]

> Подозреваю, что 4 раза - это "привет" от дельфийского компилятора.

Ну, как говориться, за что купил...

> Говорят, что сишные компиляторы попродвинутее, в том числе
> и SIMD умеют применять.

Умеют, но их нужно вот так же - хитро описывать. Векторы и прочие навороты. Вот так - что бы взять, прямо из цикла, и сконвертить в simd - пока не видел.

> Понятно, что для компиляции в SIMD нужно писать в том самом
> "ассемблерном" стиле, причём ещё более суровом из-за негибкости
> SIMD.

Ага, так и есть.

> Я точных процентов не знаю

А вот зря. Нет полноты картины.

> Хотя, конечно, против перехода на Си есть два существенных
> аргумента - Лень и Привычка :)

Да меня как-то и BASM не напрягает... Зачем еще C изучать, всё равно я на нём никогда не буду. Сильно нужно - найму кого. Что, бывает, и делаю.

← →
Игорь Шевченко © (2010-11-10 13:27) [81]

Sapersky (10.11.10 13:17) [78]

> Лень проверять, но там наверняка неоптимальное распределение
> переменных по регистрам, не соображает делать инкремент
> указателей

А ты проверь. Команда View|Debug Windows|CPU доступна в любой версии. Глядишь, пургу не будешь нести.

← →
Дмитрий Белькевич (2010-11-10 13:32) [82]

> > переменных по регистрам, не соображает делать инкремент
> > указателей

Посмотрел - делает. Грамотный компилятор. Так что, думаю, что таки процессор не поспевает, как ни удивительно.

← →
Дмитрий Белькевич (2010-11-10 13:34) [83]

В смысле - инкремент указателей делает, всех трёх сразу: inc esi, здесь всё исто.

← →
DiamondShark © (2010-11-10 13:35) [84]

> crux (10.11.10 12:56) [69]
> а в C++, например, можно, и при этом, при дизайне
> языка никто о таком вообще не помышлял?

Я ведь не против C++.

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

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

> Ну, например, software transaction memory, встроенный параллелизм,
> актеры, агенты, предпосылок для чего не было и уже не будет
> в его наследии, хотя в более гибких универсальных язхыках
> это появится или уже появилось.

Я так понял, что с историей программирования до 1990 года вы не знакомы.

> >Чего "нишево"
>Как раз в разработке полного комплекта

Вы со своими сями и русский-то скоро забудете.

"Нишевое" -- это значит "в узко-специальной области".

> Я несу светлый завет

А, не... С религией не связываюсь.

← →
DiamondShark © (2010-11-10 13:37) [85]

> Дмитрий Белькевич (10.11.10 13:26) [80]
> А вот зря. Нет полноты картины.

Мне аж самому интересно стало. Буду копать.

← →
Anatoly Podgoretsky © (2010-11-10 13:53) [86]

> Kerk (10.11.2010 13:12:16) [76]

Я знаю что - Power PC

← →
Anatoly Podgoretsky © (2010-11-10 13:55) [87]

> Sapersky (10.11.2010 13:17:18) [78]

Хорошо там, где нас нет.

← →
RWolf © (2010-11-10 13:56) [88]

> Sapersky (10.11.10 13:17) [78]
> Подозреваю, что 4 раза - это "привет" от дельфийского компилятора.

так и есть — в приведённом коде умножение скомпилируется в вызов функции _llmul (если я правильно понял, и tempdbl2 — это dword).

← →
crux (2010-11-10 13:58) [89]

DiamondShark © (10.11.10 13:35) [84]

>Я так понял, что с историей программирования до 1990 года вы не знакомы.

Ну как же. Думаете про Вирта я от вас узнал? Я и блюботл как-то даже устанавливал. Очень скучно. Только консерваторы из 80-х годов будут в нем разрабатывать приложения.

>"Нишевое" -- это значит "в узко-специальной области".

Ну я это как раз и имел в виду. Где же ваш хваленый Оберон-то? На вертолетах скорость винтов регулирует?

← →
Anatoly Podgoretsky © (2010-11-10 14:11) [90]

> DiamondShark (10.11.2010 13:35:24) [84]

Так С++ это мутанты?

← →
Anatoly Podgoretsky © (2010-11-10 14:13) [91]

> crux (10.11.2010 13:58:29) [89]

Вирт талантливый ученый, но отвратительный коммерсант, даже не понятно как
это с Паскалем получилось, но явно не благодаря ему.

← →
Дмитрий Белькевич (2010-11-10 14:20) [92]

> если я правильно понял, и tempdbl2 — это dword

Название tempdbl2 - пережитки прошлого. Нужно было переименовать, да:

TempDbl2, TempInt: integer;

Тем не менее, imul есть.

← →
euru © (2010-11-10 14:25) [93]

> Дмитрий Белькевич (10.11.10 13:01) [71]
> Кстати, в моём случае с mmx"ом, как раз параллелизм даёт
> такое увеличение. Ну, да я думаю, сами знаете.

Кстати, современные процессоры Intel содержат несколько ядер. Если посмотреть на код, написанный на ЯВУ, то видно, что теоретически ничто не мешает распараллелить его на несколько ядер. Такая возможность предусмотрена в ассемблерной вставке?

← →
Дмитрий Белькевич (2010-11-10 14:31) [94]

> Такая возможность предусмотрена в ассемблерной вставке?

Нет.

← →
RWolf © (2010-11-10 14:33) [95]

> Дмитрий Белькевич (10.11.10 14:20) [92]

на моей машине (атлон 3000+ 2 ГГц) дельфовая и ассемблерная версии показывают 25 млн и 11 млн тактов соответственно.

← →
Дмитрий Белькевич (2010-11-10 14:37) [96]

У меня на буке, Intel Core 2 Duo T9400, разница - ровно 4 раза. Тестовую обвязку прибил, если нужно - опять сделаю.

← →
RWolf © (2010-11-10 14:37) [97]

> RWolf © (10.11.10 14:33) [95]

правда, тестировал 4-Мбайт массивы.

← →
Дмитрий Белькевич (2010-11-10 14:38) [98]

Кстати, посмотрел - не исключено, что таки в кэш влазит:

6 MБ кэш-памяти, тактовая частота 2,53 Ггц.

← →
Дмитрий Белькевич (2010-11-10 14:42) [99]

Можете для 16 бит попробовать:

asm pushad mov eax, TempInt movd mm0, eax punpcklwd mm0, mm0 punpcklwd mm0, mm0 mov eax, TempDbl2 movd mm1, eax punpcklwd mm1, mm1 punpcklwd mm1, mm1 mov ecx, BuffHigh add ecx,ecx and ecx, $fffffff8 mov esi, p1 mov esi, [esi] mov edi, p2 mov edi, [edi] mov ebp, p3 mov ebp, [ebp] @@cycle: movq mm2, [esi + ecx] psubusw mm2, [ebp + ecx] pmullw mm2, mm1 movq mm3, mm0 psubusw mm3, mm2 movq [edi + ecx], mm3 sub ecx, 8 jnz @@cycle emms popad end; for i := 0 to BuffHigh{ mod 8} do Img.FBuff16[i] := word(TempInt - ((ShiftMask.FBuff16[i] - ImageSlice.FBuff16[i]) * TempDbl2));

← →
Дмитрий Белькевич (2010-11-10 14:49) [100]

FBuff16 - array of word
FBuff8 - array of byte

← →
tesseract © (2010-11-10 14:53) [101]

> Если посмотреть на код, написанный на ЯВУ, то видно, что
> теоретически ничто не мешает распараллелить его на несколько
> ядер.

Типа так ? http://ru.wikipedia.org/wiki/Grand_Central_Dispatch

← →
RWolf © (2010-11-10 14:54) [102]

> Дмитрий Белькевич (10.11.10 14:49) [100]

хм, до этого я сравнивал асм из [10] с кодом из [51].
процедуры из [99] работают практически с одинаковой производительностью.

← →
Sapersky (2010-11-10 15:25) [103]

FBuff16 - array of word
FBuff8 - array of byte

Ну если вынести всё в отдельную процедуру, работающую с элементарными типами (и передавать массивы как const) - тогда будет оптимально. Именно это я имел в виду под "ассемблерным стилем".
А вот если в точности как в оригинале, с Img, ShiftMask, ImageSlice, да ещё где-то в середине большой функции - тогда компилятор может насочинять странного. Не утверждаю, что обязательно насочиняет - но может.

← →
Дмитрий Белькевич (2010-11-10 15:33) [104]

> Ну если вынести всё в отдельную процедуру, работающую с
> элементарными типами (и передавать массивы как const) -
> тогда будет оптимально.

Угу, есть такое. Еще если обращаться к элементам массива по указателям. Но тогда получается такой pas, что уж лучше asm.

> процедуры из [99] работают практически с одинаковой производительностью.

Чуть позже на другой машине попробую еще - на семпроне 2600.

← →
RWolf © (2010-11-10 15:55) [105]

> Дмитрий Белькевич (10.11.10 15:33) [104]

я замерял время выполнения вот так: http://pastebin.ca/1987203

← →
Дмитрий Белькевич (2010-11-10 16:19) [106]

> я замерял время выполнения вот так: http://pastebin.ca/1987203

Так, на 1000-е циклов:

Коре дуо:

1.89 млрд
4.73 млрд

Семпрон:

10.54 млрд
11.53 млрд.

Таки кэш?

← →
Sapersky (2010-11-10 17:07) [107]

Вообще да, CoreDuo / данные влезают в кэш / реализация в виде отдельной функции - разница 3.5 раза.
Хм... ну значит CoreDuo любит MMX больше других... я в своё время тестировал преимущественно P4 и получал обычно около 2-х раз.
Но вариант с MMX немного странный - если mullw лихо отбрасывает старшие разряды от умножения, то что там, в этих word"ах - исключительно байты? Взятие младшего слова - это ведь не clamp (как часто хотелось бы), или я что-то путаю?

← →
Дмитрий Белькевич (2010-11-10 18:35) [108]

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

← →
Дмитрий Белькевич (2010-11-10 18:36) [109]

Но, таки да - сравнение не честное. По хорошему - лучше переписать, или с 8-ю битами пробовать.

← →
Дмитрий Белькевич (2010-11-10 18:43) [110]

It"s not a bug, it"s a feature :) Как раз тот случай :)

> В будующем 99%% программистов не будет волновать реализация
> вообще.
> Язык будет описательным.

Тут свои грабли, на которые наступаешь тогда, когда что-то перестает работать. Или работает с жуткими тормозами. В этом случае необходимо восстановить реализацию, которая сокрыта в недрах.

Причем, ощущение, что это уже проходили. В одной книжке я читал, что с появлением языка SQL программисты перестали быть нужны, ибо любой бухгалтер сможет набрать текст запроса на понятном английском языке и получить нужный ему результат :)

Лично мне проще написать что надо делать и в какой последовательности, чем устранять "непонимание", когда я думаю одно, а меня поняли совсем по другому. Ибо это проще.

← →
_oxffff (2010-11-10 19:40) [112]

А есть что по делу?

> Mystic (10.11.2010 19:35:51) [111]

Были такие фантазии у ИБМ, а кончилось тем, что появилась новая профессия, в
переводе SQL Запросчик.

А вот ещё такое соображение, навеяное соседней веткой.

Грядёт эра дешёвых параллельных архитектур. Уже сейчас четырёхядерные процессоры пихают куда попало, а двухъядерные считаются чуть ли не бюджетным решением, на серверах так уже давно количество камней ограничено лишь санитарными нормами по шуму.

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

> Дмитрий Белькевич (10.11.10 16:19) [106]

запустил на домашнем Core2Duo E6300 (2 MB L2 cache); ассемблерная процедура выполняется за ~3,7 млн. тактов, дельфовая — за ~4,8 млн.

> DiamondShark © (10.11.10 20:00) [114]

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

Если брать шахматы, то я абсолютно не понимаю, как там можно прикрутить автоматическое управление памятью и автоматический параллелизм. По первому пункту в требованиях задачи обычно стоит возможность настройки максимального размера памяти, которые движок может использовать движок. Иначе он просто сожрет все. Так что все равно, как только хэш позиций заполняется, надо думать о том, какие позиции неактуальны и должны быть удалены из него. Второй пункт входит в противоречие со всякими эвристиками типа "ходов-киллеров" и т. д. и т. п., что подразумевает изменяемые глобальные переменные.

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

Да вы просто Cuda с OpenCl не видели. Там тот же самый низкий уровень. Код надо писать для векторных данных как SSE. А параллелизмом управлять. На видео картах тежи самые проблемы с кэшем что и на проще. Главное задействовать быструю память.

Тот же Visual С++ умеет делать код который будет работать на разных ядрах. Но так никто не делают. Все используют OpneMP вставки.

По поводу того что компиляторы C++ хорошо оптимизируют это сказки. ДА лучше чем Delphi но проблемы все тежи. С чего бы в друг им использовать инстриксы или ассемблерные вставки если и так хорошо? А они используются во всех высоко оптимизированных библиотеках.

Вот и все дела инструмент вроде бы есть, а вроде бы его и нет.

← →
_oxffff (2010-11-10 20:45) [118]

> . Вот тут-то низкому уровню и ручному управлению памятью
> окончательный и бесповоротный северный зверёк.

А как связана параллельность языка с управляемой кучей?

> Ты рассуждаешь в общем, без конкретной привязки к задачам.

С "конкретной привязкой к задачам" рассуждения обычно строятся следующим образом.

Село Нижние Подмышки, Урюпинский уезд, 1810 год.
- Слышал, Петрович, чяво те агличане выдумали?
- Чяво?
- Берут воду в медный жбан запирають, да на уголья ставють. А пар-то с той воды пускают в чугунную машину.
- А эт зачем?
- А машина та колесо крутит. Хошь -- мельницу цепляй, хошь -- станок на мануфактуре.
- Мельница эвон у нас на запруде стоит. Чево на ей уголье жечь-то?
- А ещё, говорят, машину ту на колёса ставят, так она потом сама едет.
- Эк же она сама поедет? Машина-то чугунная, тяжёлая, да жбан-то, с кипятком-то. Тут пару ломовых запряги -- и то не сдвинешь.
- Дык, машина-то колёса и вертит. От того и едет.
- А каково вода-то остынет?
- Дык, к машине телегу с угольем-то цепляют, то уголье и жгут.
- Хех. Потонет-то машина в наших колдоёбинах-то.
- А её для того по железным брусьям пускают.
- Как так по брусьям?
- Да так. Кладут ровнёшенько брусья, да по тем брусьям она и едет.
- Ну, брат, либо ты про агличан врёшь всё, либо тои агличане все с катушек сбрендили. Того железа не напасёшся, уголья-то накопай, да как жбан-то лопнет, всех-то и поварит. Эх, а с лошадушкой-то нашей нигде не пропадёшь.

> Лично для меня более предпочтительны те системы, где о параллелизме
> думали с самого начала. В отличие от систем, где понадеялись
> на автоматические средства.

На самом деле, "думать с самого начала" и "использовать автоматические средства" ни в коем случае не являются взаимосключающими. Скорее, даже наоборот.

> Пока что доверия им нету большого, хотя бы потому, что я
> плохо понимаю, как это будет работать.

Argumentum ad ignoratio. Волшебно.

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

Расскажи, как возможность модифицировать переменные препятствует параллелизму?

> Если брать шахматы, то я абсолютно не понимаю, как там можно
> прикрутить автоматическое управление памятью и автоматический
> параллелизм.

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

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

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

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

> Так что все равно, как только хэш позиций заполняется, надо
> думать о том, какие позиции неактуальны и должны быть удалены
> из него.

Хочешь верь, хочешь нет, но автоматическое управление памятью этому не мешает нисколько.

> Второй пункт входит в противоречие со всякими эвристиками
> типа "ходов-киллеров" и т. д. и т. п., что подразумевает
> изменяемые глобальные переменные.

Если ветки алгоритма обращаются к глобальным переменным, то они просто не будут признаны инвариантами и будут сериализованы.

> Да вы просто Cuda с OpenCl не видели.

А вы просто параллельных языков не видели.
Да ещё и SIMD c MIMD путаете.

> Тот же Visual С++ умеет делать код который будет работать
> на разных ядрах.

И как это ему удаётся, если ОС такого не поддерживает?

> Все используют OpneMP вставки.

Это не то. OpenMP использует потоки. В лучшем случае -- пул потоков. Потоки слишком тяжёлые. А других средств в ОС нет.

Отвлекитесь от существующих ОС и реализации многопоточности в них. Я говорю не о многозадачности, а о внутреннем параллелизме алгоритмов.

> А как связана параллельность языка с управляемой кучей?

Очень просто связана. Явное управление кучей вносит паразитные зависимости, которые сильно мешают параллельности.
Примитивнейший пример:

a := new(TA);
DoInvariant1(a); // эти ветки
DoInvariant2(a); // выполняются параллельно
dispose(a); // здесь точка синхронизации, но она тут нафиг не нужна
// дальше код, независимый от а
// но он не может выполняться до завершения обоих
// DoInvariant1(a) и DoInvariant2(a)

Высокий/низкий уровень, ручное/автоматическое управление Найти похожие ветки