Здравствуйте, Pzz, Вы писали:
Pzz>Если использовать int по назначению (например, в качестве счетчика цикла), то обычно вообще все равно, 16 он бит или 32.
даа, теперь понятно откуда тонны уязвимостей integer overflow с последующим корраптом памяти...
Здравствуйте, Alekzander, Вы писали:
A>Я слышал, в старые времена железо тормозило на неродной разрядности. Например, задефайнив INT на 16 бит и используя его повсюду, можно было совершенно бесплатно получить просадку производительности на 86 времён, примерно, 9x.
Это во все времена так. Железо умеет работать только с конкретной разрядностью. Всё что другое корректируется компилятором, т.е. софтварно. Вот вам и просадка.
Здравствуйте, Pauel, Вы писали:
A>>Я слышал, в старые времена железо тормозило на неродной разрядности. Например, задефайнив INT на 16 бит и используя его повсюду, можно было совершенно бесплатно получить просадку производительности на 86 времён, примерно, 9x.
P> Это во все времена так. Железо умеет работать только с конкретной разрядностью. Всё что другое корректируется компилятором, т.е. софтварно. Вот вам и просадка.
И что, ты хочешь сказать, что современные 64-битные процы не пилятся специально так, чтобы не было просадок на тоннах 32-битного софта?
I'm a sewer mutant, and my favorite authors are Edgar Allan Poo, H.G. Smells and George R.R. Martin.
Здравствуйте, mike_rs, Вы писали:
Pzz>>Если использовать int по назначению (например, в качестве счетчика цикла), то обычно вообще все равно, 16 он бит или 32.
_>даа, теперь понятно откуда тонны уязвимостей integer overflow с последующим корраптом памяти...
Здравствуйте, Pzz, Вы писали:
_>>даа, теперь понятно откуда тонны уязвимостей integer overflow с последующим корраптом памяти... Pzz>Ну, Си не для всех...
BFE>У многих файлов и каталогов дата поменялась на 2040... и именно это приводит к проблемам. Если поменять даты каталогов /etc и /dev на текущие, то кое-что начинает работать.
Хм, интересно. похоже это бага драйвера fs. Какая там fs?
И зачем вообще системе смотреть на даты файлов? это атрибут user level.
Здравствуйте, B0FEE664, Вы писали:
BFE>Надёжная Debian 12
Я начал использовать Debian с 6 версии, с переходом на 7 версию на полный цикл. Больше всего мне нравилась 9 версия. А 12 версия на мой взгляд неудачная.
И в Debian есть выведенное мною правило, что начинать использовать выпуск нужно тогда, когда выпустили следующую версию.
Например, выпускают установочный образ 13 версии, тогда идём и скачиваем последний установочный образ 12 версии.
В последнем установочном образе уже исправили многие баги из коробки. Это лучше, чем ставить баганутый образ первых выпусков и обновления, так как реконфигурация сама по себе не делается.
В целом же Debian это рабочий инструмент. Цель его дать пользователям операционку для последующей настройки.
Для таких случаев и существует профессия администратора. Если сам не хочешь настраивать можешь заплатить. А если настраиваешь сам, то сам и становишься админом.
Здравствуйте, Alekzander, Вы писали:
A>И что, ты хочешь сказать, что современные 64-битные процы не пилятся специально так, чтобы не было просадок на тоннах 32-битного софта?
Я хочу сказать, что в любой процессор закладывается ограниченное количество кейсов для оптимизации.
Нынешние процессоры затачиваются в основном под 32 и 64 бита.
Иногда 32х битная версия быстрее, иногда 64.
Для интересу можно 16 битный код потестировать, не знаю, правда, как этого добиться.
Еще есть и 8 битные команды, вроде бы их не выбрасывали.
А вот если вы захотите 128бит — у вас снова будут просадки, как и в стародавние времена. Только поменьше, т.к. раньше в процессорах отсутствовали многие механизмы, типа буфер ветвления, кеширование итд итд
Здравствуйте, Pauel, Вы писали:
P>Нынешние процессоры затачиваются в основном под 32 и 64 бита.
"Что ж ты, фраер, сдал назад?" Сначала ты пишешь:
>Это во все времена так. Железо умеет работать только с конкретной разрядностью. Всё что другое корректируется компилятором
А теперь, значит, "затачиваются" сразу "под 32 и 64 бита", да?
Об этом и речь шла. Если верна гипотеза, что когда-то плавающий инт ввели с Си в порядке оптимизации, чтобы при переносе на другие платформы автоматически (без изменения кода) получать родную разрядность и максимальную производительность, то теперь смысла в плавающем инте больше нет. А нет смысла потому, что имея такой корпус 32-битных программ создатели 64-битных процессоров вложились в оптимизацию под "неродную", 32-битную разрядность. Хотя я даже не уверен, что там к 32-битности вообще применимо понятие "неродная".
I'm a sewer mutant, and my favorite authors are Edgar Allan Poo, H.G. Smells and George R.R. Martin.
Здравствуйте, Alekzander, Вы писали:
A>"Что ж ты, фраер, сдал назад?" Сначала ты пишешь: A>А теперь, значит, "затачиваются" сразу "под 32 и 64 бита", да?
Вы так торопитесь, что ваши мысли вас не догоняют.
Цитирую себя: "А вот если вы захотите 128бит — у вас снова будут просадки, как и в стародавние времена. "
Разница между 32 и 64 небольшая, но есть. Не нравится — рассмотрите кейсы с 16 битными вычислениями, 8 битными, и даже 128 битными.
Здравствуйте, Pauel, Вы писали:
P>Цитирую себя: "А вот если вы захотите 128бит — у вас снова будут просадки, как и в стародавние времена. "
Вот тогда, возможно, снова станет актуальным плавающий инт. А на данный момент он актуальность утратил, в связи с тем, что хорошая нативная поддержка 32-битного софта всеми процессорами это фактор конкуренции.
Если, конечно, подчёркиваю, верна гипотеза о перформансных или каких-то иных плюшках автоматического приведения разрядности к родной. А другой разумной гипотезы, собственно, я не вижу.
I'm a sewer mutant, and my favorite authors are Edgar Allan Poo, H.G. Smells and George R.R. Martin.
Здравствуйте, Pzz, Вы писали:
Pzz>Если использовать int по назначению (например, в качестве счетчика цикла), то обычно вообще все равно, 16 он бит или 32.
Очень даже есть разница.
typedef int INDEX;
int xset(int *arr, INDEX pos, int val) {
arr[pos] = val;
}
Компилируем (gcc -O -S -masm=intel):
xset:
movsx rsi, esi
mov DWORD PTR [rdi+rsi*4], edx
ret
Ой, а откуда это movsx взялось? До адреса-то расширить надо...
То же для ARM/64:
xset:
str w2, [x0, w1, sxtw 2]
ret
Тут вложенная sxtw делает то же самое.
Если взять unsigned, то для такого простого кода, да, на x86 срабатывает автозатирка старших 32 бит при 32-битных операциях (но не при 16-битных!) На ARM аналогично появляются uxtw.
А теперь ещё интереснее — делаем индекс unsigned short и делаем цикл по нему:
typedef unsigned short INDEX;
int xfill(int *arr, INDEX size) {
INDEX i;
for (i = 0; i < size; ++i) {
arr[i] = i;
}
arr[size] = 0;
}
А зачем нам аж два and с 65535? А это нас арестовывать идут есть правило C/C++, что арифметика unsigned она modulo. В результате лишние операции в цикле.
На x86 GCC на это решил использовать 16-битные регистры, типа ax. Clang не захотел, поэтому там есть явный movzx после инкремента.
А теперь ещё и поменяем аргумент размера на size_t. GCC, x86:
Два лишних movzx. Мы убрали гарантию, что предел влезает в те же 16 бит, и включается полная арифметика по модулю 2^16 в регистре размером на 2^64. Это полное орейро.
Эффект я наблюдал в коде проектов, в которых почему-то очень любили, что если количество, например, модулей железа для чего-то приходит в виде uint8_t, то и итерировать по ним надо через uint8_t. В результате код был переполнен всякими ubfx и uxtw.
Для архитектур типа ARM я уже вообще не вижу причин оставлять int 32-битным, кроме совместимости с неизвестно чем. Для x86 минимальный аргумент — что 32-битные команды в массе, в отличие от 64-битных, не требуют REX префикса, поэтому чуть экономнее.
Зато в рекомендации по кодированию давно надо внести — все переменные циклов, которые используются для индексации, надо делать size_t или ssize_t. Иначе повылазят эти конверсии где не нужны.
Здравствуйте, Pzz, Вы писали:
Ф>>А что, во время 16-битных регистров мегабайтных файлов ещё не было? Или никто последовательно не вычитывал сотни тысяч элементов структуры? Вроде когда C придумали, уже юникс был — уже должны были быть подобные задачи, тем более Масачусетском универе. Ф>>Я не сишник, если что.
Pzz>Для этого был тип long.
Здравствуйте, Alekzander, Вы писали:
A>>>Я слышал, в старые времена железо тормозило на неродной разрядности. Например, задефайнив INT на 16 бит и используя его повсюду, можно было совершенно бесплатно получить просадку производительности на 86 времён, примерно, 9x.
P>> Это во все времена так. Железо умеет работать только с конкретной разрядностью. Всё что другое корректируется компилятором, т.е. софтварно. Вот вам и просадка.
A>И что, ты хочешь сказать, что современные 64-битные процы не пилятся специально так, чтобы не было просадок на тоннах 32-битного софта?
С подходами _современных_ процессоров вообще должно быть пофиг, какая разрядность, пока речь идёт об операциях над полным объектом (обычно регистром).
Во всех основных архитектурах это обеспечено тем, что операция с младшей частью регистра чистит старшую часть. X86 — любая 32-битная операция зануляет старшую половину 64-битного регистра. ARM/64 — то же самое. RISC-V — знаковое расширение на старшую часть, но последствия те же. Или загрузка из памяти в регистр: у тебя есть какие-нибудь lb, lbu, lh, lhu, lw, lwu, ld (список по RISC-V) с расширением, но нет условного lhk (поменять младших 16 бит не трогая старшие). Нужно такое — делаешь особым комбинированием (как bfm в ARM/64), но нужно очень редко.
А вот с 8 и 16 битами в x86 иначе. Они старшую часть, какого она бы ни была размера (16, 32, 64), вообще не трогают. Для 8086 это было ещё логично: работаешь с AL, не меняешь AH. Но сделав такое правило в 386, Intel сама себе подложила огромную свинью. Те задержки, о которых ты говоришь, происходят от того, что возникает "ложная зависимость" между старым и новым значением регистра, которая не даёт параллелить операции.
Особенно это грустно было на PPro. В P2 и особенно в P3 это исправили, вместе с другими проблемами — в PPro, например, Flags рассматривался целиком, и любимые Intel подходы, что некоторые команды меняют только часть condition codes, давали тут такую же неустранимую зависимость. В P2 его разделили на каждый бит CC (CF, SF, OF, ZF, AF, PF) отдельно. Наверняка это ты и вспомнил в вопросе скорости 16-битных программ "во времена 9x".
Но я думаю, что с последними поколениями, когда 16-битный код в нормальном софте используется только для загрузки до момента перехода в защищённый режим с загруженным ядром, эту подпорку начинают убирать обратно. Хочешь легаси — не вопрос, но будет тормозить на тех же false dependency.
Здравствуйте, Pauel, Вы писали:
P>Здравствуйте, Alekzander, Вы писали:
A>>Я слышал, в старые времена железо тормозило на неродной разрядности. Например, задефайнив INT на 16 бит и используя его повсюду, можно было совершенно бесплатно получить просадку производительности на 86 времён, примерно, 9x.
P> Это во все времена так. Железо умеет работать только с конкретной разрядностью. Всё что другое корректируется компилятором, т.е. софтварно. Вот вам и просадка.
X86 таки тут особый случай. Поддержка 8- и 16-битных операций в легаси-стиле. Я в соседнем комментарии расписал подробнее.
(Честно говоря, не только он, конечно. SystemZ отличается тем же. Но там такие пользователи, что их это в большинстве случаев не волнует.)
Здравствуйте, Alekzander, Вы писали:
A>Я думаю, при переносе восьмибитных программ на практике ты всегда влезал в память, если тупо заменял главный int на 16-битный.
Насколько я понял твою хитро завёрнутую мысль, то таки нет.
Самая ходовая среди таких платформ — 6502 — имела с этим серьёзные проблемы. Позволить себе 16-битный int было чудовищно дорого.
Здравствуйте, B0FEE664, Вы писали:
BFE>По ssh не зайти, девайса в сети нет (хотя ip на нём фиксированный)
[...]
BFE>Через последовательный порт видно , что загрузка с ошибками, но проходит. BFE>putty подвисает после каждого нажатия enter, так что каждая команда требует переподключения. BFE>Обратно дату на текущую не изменить: команда завершается с ошибкой. BFE>У многих файлов и каталогов дата поменялась на 2040... и именно это приводит к проблемам. Если поменять даты каталогов /etc и /dev на текущие, то кое-что начинает работать. BFE>Я не стал дальше разбираться, а просто переставил систему с флешки.
BFE>>>А почему? А потому, что опытные программисты знают как там оно на самом деле устроено и кастят time_t к int. Pzz>>А там в хардварии сколько битов-то? BFE>ARM 64 бита.
Крайне странно. На 64 битах уже давно time_t 64-битный насквозь.
Присоединяюсь к вопросу, не виноват ли какой-нибудь код за пределами Linux (аббревиатура BSP, которую тут упомянули, в этом числе).
Здравствуйте, Alekzander, Вы писали: A>И что, ты хочешь сказать, что современные 64-битные процы не пилятся специально так, чтобы не было просадок на тоннах 32-битного софта? тынц
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, netch80, Вы писали:
N>Крайне странно. На 64 битах уже давно time_t 64-битный насквозь. N>Присоединяюсь к вопросу, не виноват ли какой-нибудь код за пределами Linux (аббревиатура BSP, которую тут упомянули, в этом числе).
И за пределами, конечно, тоже виноват. Например, sft-plugin для Total Commander вообще не видит файлы, если их дата (причём любая из трёх) уходит за порог.
Ну и Debian от больших дат глючит.
Вот, ради эксперимента под Debian12 на WSL под Windows 10:
Скажите мне, каким образом 11-ое декабря 12340 года превратилось в 11-ое мая 2446 года? Программисты опять живут сегодняшним днём? Не, я понимаю, Земля замедляется, но за 10300 лет год увеличится не больше чем на 3 минуты и это никак не объясняет, куда делись 9894 года и почему 10:09 превратилось в 00:38.
Винда, кстати, в колонке Date на эти файлы показывает пустое место. Ну, хоть ничего не падает...
Это во все времена так. Железо умеет работать только с конкретной разрядностью. Всё что другое корректируется компилятором, т.е. софтварно. Вот вам и просадка.
