- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
- 68
- 69
- 70
- 71
- 72
- 73
- 74
void sort8(uint64_t a[8])
{
uint64_t a0;
uint64_t a1;
uint64_t a2;
uint64_t a3;
uint64_t a4;
uint64_t a5;
uint64_t a6;
uint64_t a7;
SORT2(a[0], a[1], a0, a1);
SORT2(a[2], a[3], a2, a3);
SORT2(a[4], a[5], a4, a5);
SORT2(a[6], a[7], a6, a7);
uint64_t a_tmp[8];
MERGE_2_4(a0, a1, a2, a3, a_tmp[0], a_tmp[1], a_tmp[2], a_tmp[3]);
MERGE_2_4(a4, a5, a6, a7, a_tmp[4], a_tmp[5], a_tmp[6], a_tmp[7]);
uint64_t *ptra1 = &a_tmp[0];
uint64_t *ptra2 = &a_tmp[4];
for (size_t i = 0; i < 4; i++)
{
if (*ptra1 < *ptra2)
{
a[i] = *ptra1;
ptra1++;
}
else
{
a[i] = *ptra2;
ptra2++;
}
}
for (size_t i = 4; i < 8; i++)
{
if (ptra1 == &a_tmp[4])
{
while (ptra2 != &a_tmp[8])
{
a[i++] = *ptra2;
ptra2++;
}
break;
}
if (ptra2 == &a_tmp[8])
{
while (ptra1 != &a_tmp[4])
{
a[i++] = *ptra1;
ptra1++;
}
break;
}
if (*ptra1 < *ptra2)
{
a[i] = *ptra1;
ptra1++;
}
else
{
a[i] = *ptra2;
ptra2++;
}
}
}
Эта херня по итогам уделывает в скорости std::sort, если им сортировать куски по 8 элементов.
а если после него поставить точку с зопятой, то получится
{pituh(); koko();};
и будет ошибка
а
{pituh(); koko();} while(0); -- не будет
NF е колво колонок. $NF, таким образом, есть последняя колонка. Так чуваки узнавали имя текущей папки.
А, внутри if'а. Сорре.
if (petuh) {do(); all();}; //ахаха, хуй тебе а не елс
else {}
Иногда даже жалко что мне в работе такие задачи решать не приходится. Или нет. Не жалко. В жопу такое дебажить потом.
Кто-нибудь сможет быстрее сортировку на восемь uint64_t сделать (можно даже попробовать какое-нибудь SSE, если оно чем-то сможет помочь)? std::sort отстает от этого кода на GCC.
Подстраховался от эсэсёбства? 🙂
Если последнюю стадию улучшить (наанроллить) в моем варианте, можно быстрей перфоманс сделать.
Да, если с PGO оптимизировать обычный std::sort, он оба варианта уделывает по пирфомансу
https://paste.debian.net/hidden/eadc947e/ - вот код для тестов, если интересно
Теперь std::sort опять проигрывает, даже с PGO. Видимо этот std::sort по дизайну так запилен, чтоб частично сортированнные массивы досортировывать (досортировывать массивы из одних нулей - легко!), а если еще PGO использовать, то тогда вообще супер быстро получается.
https://paste.debian.net/hidden/368b30a7/
https://paste.debian.net/hidden/d6c6cd71/ тестовый код
Вывод времени
time = 154968303
time = 149922928
time = 151220900
time = 150623575
Для GCC-8 всё сильно медленней:
time = 381412656
time = 381636722
time = 381310683
time = 379839114
(тогда можно будет увидеть саму функцию в ненаанролленом виде).
И что же мы видим в случае clang?
куча сравнений и условных мувов.
Что же касается GCC:
Мы видим кучу меток и условных переходов, тут явно какой-то косяк компилятора. Надо будет в багзиллу GCC ченить накатать по этому поводу.
sssssssssse3
Кстати можно на stm'ке с NEONом попробовать.
http://www.greenarraychips.com/home/documents/greg/PB001-100503-GA144-1-10.pdf
... можно срать в два унитаза в сорок тысяч раз быстрей.
https://lwn.net/Articles/740157/
там еще файрволы можно делать в юзерспейсе оказывается
а вот этот чел сделал мой день
Next step: JavaScript in the kernel.
/me runs and hides.
Ты описывал фильтры на спец языке, который потом в ядре выполнялся (ну как aml например).
А в лялихе потом додумались его юзать и для файра и для трейсинга
С 256-битными интринсиками получилось вроде красиво (каждый сортирующий слой из cmpgt + blend + blend и между ними небольшие перестановки по 1-2 инструкции), но почему-то на треть медленнее невекторизованной битонки. Неужели AVX такой тормозной?
oa = a < b ? a : b;
ob = a < b ? b : a;
почему его только сейчас заметили?
Серьёзно, производители кококонпеляторов знают про «SSE» и «AVX», но игнорируют «CMOV»?
Хотя с другой стороны, в 32- и 64-битном режимах с появлением s-i-b (scale-index-base) она и вправду стала не нужна.
это правда
x86 та еще помоечка:)
Я знаю кое-кого кто даже debug registers не использует до сих пор
То ли дело «PDP-11», у которого любую инструкцию можно было использовать с любым набором регистров (было всего несколько исключений для спецрегистров).
Даже «ARM» кококококонсистентнее, потому что у него предикаты есть у всех инструкций, а не только у «CMOV».
Всё равнои ли поздно порастает пиздой: языки, фреймворки, операционные системы, программы, и ISA процессоров
потому раз в 15 лет надо всё обссыкать, сжигать и начинать с ноля.
Ну вот Интел попробовал Итаниум, но пидарасы с софтом 1989 года не дали ему этого сделать
Наример в BSD принято собирать софт для конкретной версии ОС и потому они могут позволить себе ломать и ABI ядра и что угодно.
в линуксе так не делают (торвальдс больно бьет по рукам за слом abi), так что там тоже много легаси говна
но они его депрекейтят по-тихоньку
https://yarchive.net/comp/linux/cmov.html
ARM Линусу похуй я думаю, он спец по x86 больше.
но потом прогнулся
http://lwn.net/2000/0914/a/lt-debugger.php3
а потом такой
https://www.kernel.org/doc/html/v4.18/dev-tools/kgdb.html
правда, она уже не нужна с тех пор как MCH отменили
Кстати, в некоторых ОС керлендебагеров так и нет, и ничо: живут как-то
Зато вот в винде он был уже очень давно, да какой няшный
Погуглил... Я проспал появление «Моста Песочка» и «Ускоренной единицы обработки».
может быть до сих пор называл его северным мостом?
А песочный мостик это уже следующее коколение.
У нехалема были еще всякие цветочные поля, какие-то там леса итд
а песчаный мостик превратился потом в ивовый мостик
А сейчас у нас эпоха озер: у меня есть небесное озеро, например
6800 и 68000.
то моторолла
а то интел
НЦ-8020 например
Кста, когда интел стали клонировать он решит запатентоваться.
И вот когда оказалось что патентовать цЫфры нельзя, он назвал проц pentium, хуй знает что это значит
Были серии с укороченным названием T34, Т36, Т37 (вместо длинных КР580, К1810).
Были микропроцессоры с буквами ВП, ВЕ, ИК, ХЛ вместо ВМ.
У «Эльбрусов» и сейчас такие наименования: 1891ВМ10Я, 1891ВМ11Я.
там кодируется много чего
https://www.kingston.com/ru/memory/valueram/valueram_decoder
Да почти у всех чипов ебанистические названия, на самом деле. Тут скорее пекашные процы - исключение.
• Операционная система: OS/2.
• Интерпретатор скриптов: PL/1.
• Система управления базами данных: DB/2.
OS/2 и PS/2.
А есть продут [smthng]/0 ?
PL/0 есть. Вообще у PL/1 много диалектов.
>> In the third and last edition of his book on compiler construction, Wirth replaced PL/0 with Oberon-0.
Интересно, существовала ли Модула-0 или Ада-0.
Ох, а то я уж подумал, что на таком настоящие программы писали.
Современные школьники наверно уже и языки без замыканий считают говном.
pl/1 там был только для юзерспейса
мысль писать кернелспейс на ЯПе выскоуровня родилась вперавые у керниганов с ричами
Слишком очевидно, что это одно и то же, названное разными словами. Аргумент - это фактический параметр.
Тонкости нужны только в лямбда-исчислении и при построении трансляторов.
ух ты, такая штука есть и в питоне и в руби и в луа и даже в перле в енкотором смысле
теперь вот и в JS
причем скобки можно как угодно расставлять
именно по этому я за перл
А это уже сомнительная фича.
Ну то есть хорошо бы два режима - "скалярный", когда она включена и "векторный", когда выключена, по умолчанию - "векторный"
(Это я исходя из опыта работы с JS, где можно в переменной хранить сначала число, потом - после усложнения логики программы - массив или объект, что вызовет глюки, если "скалярный" режим работает по умолчанию)
https://wandbox.org/permlink/IxOATTwP2gBcbNwE
А ещё есть прикольный «std::tie()», но он ебанутый.
Programming Language for Division by Zero?
http://govnokod.ru/24481#comment420978
http://govnokod.xyz/_24481/#comment-376917
То ли дело EP4CE22F17C6N.
например, у меня есть записи
Это разные записи, если кто не заметил. Очень удоьно
А что там помнить? LUT'ы, регистры, умножители, память, PLL'ки, I/O блоки. Она по структуре проще многих контроллеров, на самом деле.
Это ж не проц... Напишешь - будут (если влезут, конечно).
как н проц?
о чем ты/
и DRAM перестали делать
и DRAM перестали делать
То ли дело SoftICE (RIP)
https://godbolt.org/z/yLGWmR - использована опция "-x c" - если ее убрать, cmov-ы пропадут. Поэтому я за Си.
на случайных данных будет оччень малая вероятность, что на первом же 64-битном куске оба числа будут одинаковы (если быть точным, вероятность эта равна 1/18446744073709551616 - вероятность случайно угадать 64-битное число)
а процедура обмена двух uint1024_t уже будет достаточно дорогой. Но можно не менять сами uint1024_t, а хранить некий вспомогательный массив индексов
А потом уже в конце можно пораспихивать все эти массивчики через этот говномассив с перестановками, но если мы сортируем большой массив (а не кусочками по 8 штук) то у нас от прыганья по этим индексам будет промахи кэша, в общем тут много чего можно понапридумывать с этим говном