Здравствуйте, BulatZiganshin, Вы писали:
_>>О, если у тебя есть доступ к icc, то можешь сравнить на нём разницу между вариант со включенной векторизацией и выключенной на таком http://rsdn.ru/forum/flame.comp/6072279
(count=500, width=1920, height=1080) тесте? А то у меня gcc выдаёт на haswell xeon ускорение всего где-то в 3 раза, что как-то не очень для AVX2... BZ>вот-вот. ты хоть знаешь, сколько сложений за такт может выполнить этот хасвел?
Throughput — The number of clock cycles required to wait before the issue ports are free to accept the same instruction again. For many instructions, the throughput of an instruction can be significantly less than its latency.
То есть при нормальном interleaving, без лишних зависимостей по данным, за такт можно выполнить две _mm256_add_epi32 на одном ядре, то есть 16 32-х битных сложений.
Здравствуйте, alex_public, Вы писали:
EP>>Конечно лучше когда значения явно кэшируются в регистрах, но тем не менее в этом случае повторная закачка происходит всего лишь из L1. _>Не факт. Там же всего 64 байта на линию, а мы грузим 32 байтными кусками со сдвигом в 4 байта.
В L1 хранится не одна кэш-линия. В твоём примере все используемые повторно данные будут максимум в L1.
EP>>Можешь сделать другой тест — выбери такие размеры изображений, чтобы они целиком умещались в L1 (в твоём примере ЕМНИП они в аккурат вываливались из L3 в RAM) — тогда вклад непосредственно вычислений в суммарное время будет намного больше, и получится более точно оценить непосредственно эффект от AVX2.
_>Ну уменьшил высоту в 10 раз и увеличил количество циклов в 10 раз. В итоге стало считаться не 1,31 с, а 1,17 с. )
А какой конкретно процессор? Какой объём L3?
Нужно уменьшать не в 10 раз, а намного больше. С десятикратным уменьшением ты попадаешь в L3, а надо в L1, размер которого на Haswell — 64KiB.
Здравствуйте, BulatZiganshin, Вы писали:
BZ>1) твои рассуждения бессмысленны, поскольку невозможно рассуждать о быстродействии, не зная микроархитектуры BZ>2) я прикинул оптимальный скалярный и avx2 код и у меня получилась разница в скорости в районе 6 раз
Интересно только почему твоя сложная оценка на основание огромных знаний о микроархитектуре в точности совпала с давным давно озвученным мною значение, полученным видимо на основе бессмысленных рассуждений? )
BZ>3) твой тест мог упереться в скорость озу, как я сказал в пред. сообщении
Это не верно. Точнее действительно проблема в памяти, но не в том смысле, что ты думаешь (типа надо сделать размер данных поменьше и всё будет ОК).
BZ>4) несложно самому написать оптимальный avx2-код на mm256_* операциях и посмотреть его скорость
Здравствуйте, Evgeny.Panasyuk, Вы писали:
_>>Ну уменьшил высоту в 10 раз и увеличил количество циклов в 10 раз. В итоге стало считаться не 1,31 с, а 1,17 с. ) EP>А какой конкретно процессор? Какой объём L3?
Haswell Xeon, 8 МБ.
EP>Нужно уменьшать не в 10 раз, а намного больше. С десятикратным уменьшением ты попадаешь в L3, а надо в L1, размер которого на Haswell — 64KiB.
Даже если до 20КиБ уменьшить, то ничего не меняется. )
Здравствуйте, alex_public, Вы писали:
_>Интересно только почему твоя сложная оценка на основание огромных знаний о микроархитектуре в точности совпала с давным давно озвученным мною значение, полученным видимо на основе бессмысленных рассуждений? )
какова вероятность случайно в точности угадать целое число от 1 до 8?
BZ>>3) твой тест мог упереться в скорость озу, как я сказал в пред. сообщении
_>Это не верно. Точнее действительно проблема в памяти, но не в том смысле, что ты думаешь (типа надо сделать размер данных поменьше и всё будет ОК).
гм. судя по тому что у тебя программа ускорилась от уменьшения размера данных — ты таки упирался в скорость ОЗУ. и никакой компилятор тебе скорость озу быстрее бы не сделал и соответственно твою программу бы не ускорил. а вот с уменьшенным размером данных ты упираешься в тупость компилятора. коэффициент тупости равен частоте твоего процессора, делённой на 1.3 ГГц
_>Предложишь вариант? )
лень. попробуй сам — там должна быть куча add_epi32. ещё cmp+blend для if, но их для начала можешь опустить. а остаток строки можешь вовсе не обрабатывать — для тестов скорости это мелочь
Здравствуйте, VladD2, Вы писали:
Г>>И всё же. Есть, скажем, сто ступенек (не стотысяч, нет). Тебе неинтереснен Немерле на двадцатой? «Всё или ничего», обгоняем в популярности C++ или ненавидим весь мир?..
VD>Проблема в том, что их даже не 100, а 1 000 000. И, да, мне не интересен локальный успех. Я максималист.
Позволь я подсуммирую твои высказывания:
1. есть два уровня популярности — «мейнстрим» и «не мейнстрим»
2. на уровне «мейнстрим» находятся 5-6 языков в лучшем случае
3. между этими уровнями огромный разрыв, а вот внутри каждого уровня всё примерно одинаково (пишут ли на языке 300 человек в каждом крупном городе или 50 человек во всём мире — не имеет значения, если язык «не мейнстримный»)
4. переход из уровня «не мейнстрим» на уровень «мейнстрим» происходит одним резким прыжком
5. ...и только за счёт мегапиара с огромным вливанием денег
6. ...если этого ресурса нет, то любые мероприятия по постепенному повышению распространённости языка бессмысленны
7. ...при этом ты надеешься, что Nemerle этот переход однажды таки совершит
8. ...а то что до сих пор не — проблема среднего уровня развития современных мейнстримных программистов
Здравствуйте, Mamut, Вы писали:
M>О да. Ведь по-твоему оскорбления и позиция «я — д'Артаньян, вы — тупое стадо» — это технические аргументы. Извини, таких «технических аргументов» не имею
Я конкретно с тобой так разговариваю.
С нормальными людьми я разговариваю нормально.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Гест, Вы писали:
Г>8. ...а то что до сих пор не — проблема среднего уровня развития современных мейнстримных программистов
Вот чОрт, всегда виноваты эти мейнстримные программисты. Никак не могут парадокс блаба преодолеть, вместо этого, бездельники, гоняются за экономическим профитом.
Здравствуйте, Mazay, Вы писали: M>Я же сказал — я перепутал.
Ну, а претензию то ты свою обратно берешь? Или отсутствие аргументов наездов не отменяет? M>Это называется "особенности" реализации алгоритма. По сути неэффективная реализация. Их там сохраняют потому что иногда после модификации неэффективной реализации она может стать самой быстрой.
Включи же логику, наконец! Раз особенности реализации так сильно влияют на результат, значит и сравнивать компиляторы на них некорректно.
Ты же программист. Ты же должен уметь логически мыслить. Или раз тебе не выгодно, то можно плевать на логику? VD>>Подтверждение чего? Опровержение чего? Вроде там результаты D на уровне С-шных. M>Ну вот такой взгляд разработчиков языка на результаты тестов и множит на ноль все его перспективы в HPC.
Какой, такой? Что ты несешь? По твоей ссылке D показывает результат близкий к C-шным. В одном из тестов он даже выше С-ишных. В других отстает на десятую секунды. Какое это на фиг оставление? Какой-нибудь VC++ отстанет намного больше. M>D по всем тестам медленнее C.
Не правда. В matmul:m он быстрее. В остальных если и медленнее, то на сущие копейки. M>Даже на наивном умножении матриц. Это как надо накосячить в компиляторе, чтобы получить просадку на такой элементарной вещи?
Ты высосал проблему из пальца и подгоняешь факты под свои утверждения. Там тупо разные библиотеки используются, а может и разные версии того же GCC.
Разница при этом в пределах статистических погрешностей, но ты натягиваешь сову на глобус и делаешь феерические завлечения. M>Там машинный код должен быть один-в-один. Если у них бэкэнд от GCC, то что же там надо было навертеть в IR? Вот у clang++ правильный подход. Если им присылают код, который на gcc компилируется в более быстрый, то они заводят багу.
Кончай нести пургу. Иди открой исходники и посмотри на них. Посмотри как написана С-шная версия^:
Скрытый текст
#include <stdio.h>
#include"khash.h"
KHASH_MAP_INIT_STR(str, int)
#define BUF_SIZE 0x10000
#define BLOCK_SIZE 0x100000
int main(int argc, char *argv[])
{
char *buf, **mem = 0;
int ret, max = 1, block_end = 0, curr = 0;
khint_t k;
khash_t(str) *h;
buf = malloc(BUF_SIZE); // string buffer
h = kh_init(str);
mem = malloc(sizeof(void*));
mem[0] = malloc(BLOCK_SIZE); // memory buffer to avoid memory fragments
curr = block_end = 0;
while (!feof(stdin)) {
fgets(buf, BUF_SIZE, stdin);
k = kh_put(str, h, buf, &ret);
if (ret) { // absentint l = strlen(buf) + 1;
if (block_end + l > BLOCK_SIZE) {
++curr; block_end = 0;
mem = realloc(mem, (curr + 1) * sizeof(void*));
mem[curr] = malloc(BLOCK_SIZE);
}
memcpy(mem[curr] + block_end, buf, l);
kh_key(h, k) = mem[curr] + block_end;
block_end += l;
kh_val(h, k) = 1;
} else {
++kh_val(h, k);
if (kh_val(h, k) > max) max = kh_val(h, k);
}
}
printf("%u\t%d\n", kh_size(h), max);
for (ret = 0; ret <= curr; ++ret) free(mem[ret]);
free(mem);
kh_destroy(str, h);
free(buf);
return 0;
}
и как дишная:
Скрытый текст
[d]
import std.stdio, std.string;
void main(string[] args) {
int N = 5000000;
char[] buf;
int[char[]] h;
int max = 1, n = 0;
if (args.length >= 2) N = atoi(args[1]);
while (readln(stdin, buf)) {
int current = ++h[buf];
max = (current > max)? current : max;
if (++n == N) {
writef(h.length); writef("\t"); writefln(max);
}
}
writef(h.length); writef("\t"); writefln(max);
}
[/d]
Там есть и нормальная С++-ная версия, но по понятным причинам ее в списке результатов не:
Скрытый текст
#include <utility>
#include <iostream>
#include <unordered_map>
using namespace std;
int main(int argc, char *argv[])
{
unordered_map<string, int> h;
string s;
int max = 1;
while (getline(cin, s).good()) {
unordered_map<string, int>::iterator p = h.find(s);
if (p == h.end()) h[s] = 1;
else {
++p->second;
if (max < p->second) max = p->second;
}
}
cout<<h.size()<<'\t'<<max<<'\n';
return 0;
}
Там разные хэш-таблицы используются и совершенно разный уровень битовыжимания. В D — это прекрасно читаемый код использующий встроенные хэш-таблицы, а на С-и — куча мелких оптимизаций и рукапашная работа с памятью.
Хочешь сравнить компиляторы? Напиши одинаковую реализацию хэш-таблицы. В конце концов D-и без проблем позволяет те же малоки дергать. VD>>Если результаты одного языка отличаются, то где гарантии, что дело не в том как написан тест, а именно в компиляторе? M>Я в этом посте выше написал про "особенности" реализации.
Ты сам себе противоричешь. В одной строке ты утверждаешь, что алгоритмы эквивалентны, а в другом говоришь о каких-то там особенностях реализации. Чтобы сравнивать кодогенерацию нужно иметь эквивалентный код. Понимаешь? Инструкция в инструкцию.
Ежу понятно, что если у тебя в алгоритме используется хэш-таблица, то результат его работы, во многом, будет зависеть от качества ее реализации и от качества хэш-функции. M>Никогда нельзя быть уверенным, что ты что-то не упустил, но если ты хочешь показать, что какой-то язык/компилятор крут — ты всегда можешь сравнить код и машинный код с самой быстрой реализацией (на другом языке) и поправить свой код. Если это сделать не удаётся — это баг.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, BulatZiganshin, Вы писали:
BZ>гм. судя по тому что у тебя программа ускорилась от уменьшения размера данных — ты таки упирался в скорость ОЗУ. и никакой компилятор тебе скорость озу быстрее бы не сделал и соответственно твою программу бы не ускорил. а вот с уменьшенным размером данных ты упираешься в тупость компилятора. коэффициент тупости равен частоте твоего процессора, делённой на 1.3 ГГц
Только вот фокус в том, что если мы заменим приведённый алгоритм на что-то вроде a[x]=b[x]+c[x]; при том же объёме данных, то как раз получим то самое ускорение в 6 раз от векторизации. ))) Хотя великим теоретикам микроархитектур такое наверное сложно предвидеть. )))
_>>Предложишь вариант? ) BZ>лень. попробуй сам — там должна быть куча add_epi32. ещё cmp+blend для if, но их для начала можешь опустить. а остаток строки можешь вовсе не обрабатывать — для тестов скорости это мелочь
Почему-то я не сомневался именно в таком ответе. )
Кстати, gcc и clang сейчас поддерживают гораздо более удобную векторизацию через перегрузку операторов для __attribute__ ((vector_size(32))). Но здесь все эти варианты не пройдут — нужен чистый ассемблер.
Хотя в начале было бы ещё интересно посмотреть на результат icc для этого кода, вдруг он достаточно умный...
Здравствуйте, alex_public, Вы писали:
_>Только вот фокус в том, что если мы заменим приведённый алгоритм на что-то вроде a[x]=b[x]+c[x]; при том же объёме данных, то как раз получим то самое ускорение в 6 раз от векторизации. ))) Хотя великим теоретикам микроархитектур такое наверное сложно предвидеть. )))
в этом случае расклад будет совсем другой. а главное для тебя, практика — больше шансов что тупые компиляторы смогут это сами правильно векторизовать
_>Кстати, gcc и clang сейчас поддерживают гораздо более удобную векторизацию через перегрузку операторов для __attribute__ ((vector_size(32))). Но здесь все эти варианты не пройдут — нужен чистый ассемблер.
есть всякие библиотеки, посмотри в частности у агнера фога. и зачем тебе чистый ассемблер? лучше чем с интринсиками тут даже я не напишу
_>Хотя в начале было бы ещё интересно посмотреть на результат icc для этого кода, вдруг он достаточно умный...
это запросто. у меня вообще одна программа (кажись тот самый crc32) давала наиболее быстрый x64 код с msvc2013, а x86 — с msvc2010
только непонятно что ты дальше с этим делать будешь? перейдёшь на этот компилятор? ручная векторизация по крайней мере означает что дальше у тебя всё будет работать независимо от компиляторов и их ключей
Здравствуйте, antropolog, Вы писали:
A>я тебе ещё раз говорю, это факт
А, ну, раз ты сказал, то конечно.
A>чтобы не пустопорожнить — обоснуй свои слова хоть каким нибудь алгоритмом на ассемблере, можешь хоть гуглить, хоть сам написать.
Это ты что-то там утверждаешь. Вот и обосновывай свои утверждения, а не распространяй мифы.
Я же озвучиваю одну очень простую мысль. Человек всегда можно разобраться в конкретном частном случае и найти для него оптимальное решение. Автомат же делает только то, что в него заложили автор. Учли авторы некоторый частный случай — будет для него оптимальный код. Не учли, не будет. Вопрос лишь в требуемых знаниях и усилиях. И вот усилия то оказываются неприемлемыми. По сему на ассемблерах практически никто не пишет в наше время. Овчинка выделки не стоит (ц).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Я же озвучиваю одну очень простую мысль. Человек всегда можно разобраться в конкретном частном случае и найти для него оптимальное решение. Автомат же делает только то, что в него заложили автор. Учли авторы некоторый частный случай — будет для него оптимальный код. Не учли, не будет. Вопрос лишь в требуемых знаниях и усилиях.
скажи, а в шахматы человек тоже сможет любой компьютер обыграть — хоть сейчас, хоть через 100 лет?
Здравствуйте, Ikemefula, Вы писали:
I>Вот чОрт, всегда виноваты эти мейнстримные программисты. Никак не могут парадокс блаба преодолеть, вместо этого, бездельники, гоняются за экономическим профитом.
Они только думают, что гоняются. На самом деле они нагревают вселенную своим непроизводительным трудом.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Гест, Вы писали:
Г>Позволь я подсуммирую твои высказывания:
Г>1. есть два уровня популярности — «мейнстрим» и «не мейнстрим» Г>2. на уровне «мейнстрим» находятся 5-6 языков в лучшем случае
Пока все верно.
Г>3. между этими уровнями огромный разрыв, а вот внутри каждого уровня всё примерно одинаково (пишут ли на языке 300 человек в каждом крупном городе или 50 человек во всём мире — не имеет значения, если язык «не мейнстримный»)
Не то что одинаково, но до этого самого мэйнстрима огромная пропасть.
Г>4. переход из уровня «не мейнстрим» на уровень «мейнстрим» происходит одним резким прыжком
Этого я не утверждал.
Г>5. ...и только за счёт мегапиара с огромным вливанием денег
Это важный фактор наличие которого очень способствует попаданию в разряд "мейнстрим".
Г>6. ...если этого ресурса нет, то любые мероприятия по постепенному повышению распространённости языка бессмысленны
Тут как в спортлото, всегда есть шанс, пусть даже один на миллион. Наличие баблыа и пиара существенно повышает этот фактор.
Г>7. ...при этом ты надеешься, что Nemerle этот переход однажды таки совершит
Не знаю. В начале, по наивности, я думал, что людям достаточно просто наличия более совершенного языка. Что недоработки в компиляторе, документации, IDE и переносимость можно будет побороть силами комьюнити. Но сейчас я уже понимаю, что это все наивные представления. В жизни так не происходит. По сему у меня нет иллюзий на этот счет. Плюс Немерл — это не мой язык. Я всего лишь его пользователь.
Кое что Немерл уже сделал. Шарпа с каждой версией впитывает его фичи (хотя открыто это не признается). Лет через 15, возможно, большая часть современных фич (за исключением макросов) будет и в Шарпе.
Но, я считаю, что будущее за разширяемыми языками и буду развивать эту тему даже без уверенности в успехе. Конечно, переход в разрад мэинстрима — мечта любого создателя языков. Если это случится, я буду, конечно, доволен.
Возможно, я попытаюсь создать другой язык с поддержкой расширяемости, менее элегантный, но более близкий к мэйнстрим-языку. По сему я и работаю над Найтрой, которая позволит создавать расширяемые языки с невероятно меньшими затратами сил.
Г>8. ...а то что до сих пор не — проблема среднего уровня развития современных мейнстримных программистов
Ну, проблема в людя явно есть. Прогресс в языках это явно останавливает. Этим явно пользуются большие корпорации. Незамечать это глупо. Но и списывать все только на нее тоже не верно. Я просто учитываю наличие такой проблемы. Цинично строю в своем мозгу адекватную картину мира.
Г>Ничего не упустил?
Перевернул все с ног на голову, а так — нет.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, BulatZiganshin, Вы писали:
BZ>скажи, а в шахматы человек тоже сможет любой компьютер обыграть — хоть сейчас, хоть через 100 лет?
Конечно сможет, если будет иметь в руках компьютер и неограниченное время. Компьютер, сам, думать не умеет. Он автомат. Его всего можно обойти. Вопрос только в усилиях. Разве что изобретут искусственный интеллект.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>Я же озвучиваю одну очень простую мысль. Человек всегда можно разобраться в конкретном частном случае и найти для него оптимальное решение. Автомат же делает только то, что в него заложили автор.
есть какие-то основания полагать человека более могутным, чем машина Тьюринга с нескончаемым источником настоящих случайных чисел?
VD> Вопрос лишь в требуемых знаниях и усилиях. И вот усилия то оказываются неприемлемыми. По сему на ассемблерах практически никто не пишет в наше время. Овчинка выделки не стоит (ц).
Здравствуйте, VladD2, Вы писали: VD>Конечно сможет, если будет иметь в руках компьютер и неограниченное время.
таким образом, нам удалось доказать что бессмертный человек сможет соптимизировать программу лучше чем любой компилятор. доказательство этого утверждения для простых смертных оставлено читателю в качестве несложного упражнения
ответ
достаточно воспитать своего ребёнка так, чтобы он потратил свою жизнь на решение этой задачи, и в том же духе воспитал и своего наследника
Здравствуйте, BulatZiganshin, Вы писали:
VD>>Конечно сможет, если будет иметь в руках компьютер и неограниченное время. BZ>таким образом, нам удалось доказать что бессмертный человек сможет соптимизировать программу лучше чем любой компилятор.
Или раз тебе не выгодно, то можно плевать на логику?
