[one_eight_seven 3]

6 hours ago, Rst7 said:

Вообще, конечно, сама по себе архитектура Intel'овских процов - говнище то еще, но хоть чуть-чуть меньше содрогания испытываешь, когда смотришь в листинг для x64, а не x86. Не зря вон Apple решил таки на ARM'ы все переводить.

У интела тоже уже очень давно RISC под капотом, а сверху аппаратная надстройка для обеспечения бинарной совместимости со старым CISC'ом. То есть, виной этой ужасной архитектуре - куча софта, но ничего - операционки под AARCH64 уже имеются, серверное ПО тоже появляется во всё больших количествах, а Java приложениям так и вовсе нет дела на какой операционке выполняться, JIT под AARCH64 тоже имеется.

Quote

У меня создаётся ощущение, что популярность IA-32/64 на рынке вовсе не из-за того

IA64 уже давно нет на рынке. IA32 уже доживает своё: я уже давно не ставлю библиотеки i386 при наличии версии x64, и таких людей всё больше, уже есть целые компании, объявившие, что закрывают поддержку 32-разрядных версий программ. Пока остаётся AMD64 (она же x64) и набирающая вес AARCH64 (ARM)

[Rst7 5]

1 hour ago, one_eight_seven said:

У интела тоже уже очень давно RISC под капотом, а сверху аппаратная надстройка для обеспечения бинарной совместимости со старым CISC'ом.

Это неважно. Важно то, как это выглядит с точки зрения программиста. Если нет ортогональности - компиляторы сильно проигрывают.

 

1 hour ago, one_eight_seven said:

операционки под AARCH64 уже имеются

Любые *nix'ы, например. MacOS в том числе, кстати, там и так одна и та же ОС в двух таргетах работает, один из них - ПК, другой - телефоны/планшеты на AARCH64. Вот собираются и ПК перевести на унифицированную архитектуру, так сказать.

1 hour ago, one_eight_seven said:

серверное ПО тоже появляется во всё больших количествах

Да как бы все это "серверное ПО" получается автоматически при сборке *nix'ов под новое ядро.

1 hour ago, one_eight_seven said:

а Java приложениям так и вовсе нет дела на какой операционке выполняться, JIT под AARCH64 тоже имеется.

Да кому они нужны эти жаба-приложения?

[one_eight_seven 3]

38 minutes ago, Rst7 said:

Да кому они нужны эти жаба-приложения?

Тот самый Enterprise, который обеспечивает немалую долю продаж компьютеров. Хотя, им, действительно всё-равно, там давно уже правят бал облака и виртуальные машины, а что за железо это всё крутит, по большому счёту - до лампочки.

38 minutes ago, Rst7 said:

Да как бы все это "серверное ПО" получается автоматически при сборке *nix'ов под новое ядро.

Нет, это работает (в общем случае) только для no-arch приложений. Использование FPU, SIMD и прочих шалостей нередко требует переписывания вручную. Этого компиляторы пока ещё не умеют, но начинают уметь всё больше и больше.

Изменено 10 мая, 2020 пользователем one_eight_seven

[Rst7 5]

Just now, one_eight_seven said:

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

Да этого где-то в паре-тройке inner-loop'ов может есть десяток-другой инструкций. Ничего сложного в самом ручном переписывании нет.

[RobFPGA 27]

Приветствую!

3 minutes ago, Rst7 said:

... Ничего сложного в самом ручном переписывании нет.

Ну разве что это очень дорого  - особенно для Enterprise. 

Удачи! Rob.

[one_eight_seven 3]

1 minute ago, Rst7 said:

Да этого где-то в паре-тройке inner-loop'ов может есть десяток-другой инструкций. Ничего сложного в самом ручном переписывании нет.

Знаю, переписывал, но это работает только там, где это пара-тройка циклов и не требуется огромный объём тестирования.

Также зашёл сейчас на сайт загрузок Cadence, открыл Xcelium, а там - только x86 для RHEL 6,7 и SLES 11. Понятно, что можно поставить ARM, поднять на нём виртуалку с RHEL, и работать, но сам факт - что программе нужна бинарная совместимость с интеловской/AMD'шной архитектурой

[Rst7 5]

1 hour ago, one_eight_seven said:

но это работает только там, где это пара-тройка циклов и не требуется огромный объём тестирования.

 

Да всегда там пара-тройка циклов. А то и скорее всего вообще сторонняя библиотека типа fftw, которую давно портировали ;) А если больше - то это что-то такое специфическое, которое совсем не надо каждый день на другую архитектуру портировать. И скорее всего - вообще не надо.

1 hour ago, one_eight_seven said:

только x86

Ничего, перекомпилируют, когда время придет. Сто процентов нет там привязок к x86. Ну вот не верю я (читай - мой уже, блин, немалый инженерный опыт подсказывает), что там прям нужны какие-нибудь SSE4-инструкции.

1 hour ago, RobFPGA said:

Ну разве что это очень дорого  - особенно для Enterprise. 

Да ладно вам. Кодерки средней руки щас по рублю пучок. А других для этого сегмента и не надо.

[one_eight_seven 3]

1 hour ago, Rst7 said:

Ничего, перекомпилируют, когда время придет. Сто процентов нет там привязок к x86. Ну вот не верю я (читай - мой уже, блин, немалый инженерный опыт подсказывает), что там прям нужны какие-нибудь SSE4-инструкции. 

Это инженерный опыт создания компиляторов?

[Rst7 5]

9 minutes ago, one_eight_seven said:

Это инженерный опыт создания компиляторов?

Ах простите, Xcelium - это симулятор же, да? Ну что, если уважаемым удалось распараллелить вычисления, используя всякие SSE - только честь им и хвала. Я почему-то подумал про компилятор, потому это мое возражение снимается. Значит просто перепишут, тем более, что на сайте вроде пишут, что 

Quote

Supports x86, Arm^®, and cloud compute platforms

 

[Alex77 4]

В 07.05.2020 в 22:45, Zoltrix сказал:

Вы путаете теплое с мягким.... В Виндовс ХП, как и в других 32-битных ОС есть ограничение на объем исполняемого программного кода. Объём данных может обрабатываться любой. Например, видеоконвертером, который занимает в ОЗУ 50 МБ, вы можете обрабатывать видеофайл размером 10 ГБ... И никакая 32-битная ОС вам не помешает это делать. Тем более есть режим РАЕ - возможность пропатчить ОС и отключить ограничение в 4 ГБ. Любая 32-битная ОС адресует 64ГБ ОЗУ, а 4 ГБ - это маркетинговое ограничение для продвижения х64.

Опишите процесс (алгоритм) работы с данными от 64Гигобайт объёмом (к примеру) на ВинХР ? При условии что для выполнения задачи требуется "одномоментный/параллельный" доступ к данным. Другими словами это не обработка видео/звука/не архивирование.

ПС: работодателю "пофиг" какая виндовс - ему нужен результат, а результат можно достичь только в 64 битной системе. Из актуальных 64 битных систем из семейства виндовс есть только Вин10.

ПСПС: Ваше брызгание слюной оного руководителя совсем не вдохновит и он выпрет вас пинком под зад  в дальнее эротическое путешествие. А что вы в данном путешествии будете кушать - это Ваша проблема.

[Zoltrix 4]

1 hour ago, Alex77 said:

Опишите процесс (алгоритм) работы с данными от 64Гигобайт объёмом (к примеру) на ВинХР ? При условии что для выполнения задачи требуется "одномоментный/параллельный" доступ к данным. Другими словами это не обработка видео/звука/не архивирование.

Любая 32-битная программа может занимать максимум 2 ГБ памяти на процесс (или 3 ГБ если скомпилирована с особым флагом). Это ограничение на х32 систем, это огрничение х32 приложений, т.к в х64 системе, х32 приложение имеет теже ограничения. Причем речь идет про область программного кода, а не область обрабатываемых данных. Т.е. это не мешает архиватору размером 10 МБ паковать архив размером 5 ГБ, так как одномоментно столько памяти не резервируется.

 

А почему вы мыслите "одномоментно"? У вас что выполняется только 1 программа?... Явно их множество. РАЕ позволяет запустить одновременно несколько программ, все процессы которых в сумме будут занимать хоть 50 ГБ. Для ХПишки на современном компе РАЕ это просто находка, так как позволяет фактически все загнать в ОЗУ и получить мгновенный отклик, который Win10 даже не снился.

 

Пример работы ХП с РАЕ:

[Alex77 4]

5 минут назад, Zoltrix сказал:

Любой х32 процесс может занимать максимум 2 ГБ памяти на процесс или 3 ГБ если скомпилирован с особым флагом. Но в х64 системе, х32 приложение имеет теже ограничения. Причем речь идет про область программного кода, а не область обрабатываемых данных. Т.е. это не мешает архиватору размером 10 МБ паковать архив размером 5 ГБ, так как одномоментно столько памяти не резервируется.

 

А почему вы мыслите "одномоментно"? У вас что одновременно выполняется только 1 программа?... Явно их множество. РАЕ позволяет запустить одновременно несколько программ, все процессы которых в сумме будут занимать хоть 50 ГБ.

 

Вот ХП с режимом РАЕ:

Да Вы батенька и читать не умеете от слова "совсем"

1) кому нафиг сдались 32 битные программы по 64 битной ОС ? 32 оставлен из-за  поддержки "старого ПО" - того что замечательно работало до вин7 х86. Только для случаем когда дешевле использовать то что уже работает и "новое" не требуется.

2) я конкретно сказал что задача  НЕ является архивацией данных ( где доступ осуществляется последовательно).

3) мыслю одномоментно - потому что есть ПО состоящее из одной задачи (процессса) и которое обрабатывает достаточно "безумно" много данных.

4) оные данные должны обрабатываться не последовательно, а со "случайным" доступом (к примеру к первому байту и последнему).

Где Ваш алгоритм (как сиё может обрабатываться в вин 32) показывающий преимущества "32 битной ОС винХР" над "Вин 10 64бит" ?

и нафига мне скриншот о 8ГБ ОЗУ, когда речь идёт о максимум 3ГБ адресного пространства для конкретного процесса ?

[Rst7 5]

2 hours ago, Alex77 said:

Другими словами это не обработка видео/звука/не архивирование.

Вы плохо думаете об обработке видео/звука ;) При нелинейном монтаже крайне желательно иметь произвольный быстрый доступ к любым данным. Как бы можно и в 32 бита, частями файлы маппить в адресное пространство, так и делали в уже доисторические времена,  но очень геморойно это, а с 64тибитной архитектурой все куда веселее и удобнее.

[Alex77 4]

1 час назад, Rst7 сказал:

Вы плохо думаете об обработке видео/звука ;) При нелинейном монтаже крайне желательно иметь произвольный быстрый доступ к любым данным. Как бы можно и в 32 бита, частями файлы маппить в адресное пространство, так и делали в уже доисторические времена,  но очень геморойно это, а с 64тибитной архитектурой все куда веселее и удобнее.

"Ежу понятно" что можно мапить - но это ещё тот геморррр и тормозззз.

Я не думаю плохо за видео/звук - просто мои практические знания ограничены только кодированием и воспроизведением оного контента.

Мне просто очень интересно как винХР 32 уделывает наповал вин10 64. в такого рода вычислениях (за которые дают денюшки на работе, и чем быстрее "посчитаешь" тем больше заработаешь).

Практического смысла в промышленных масштабах любых виндов 32битных нет НИКАКОГО. И ковыряться в левых (допиленных кем то) драйверах, ставить и молиться что не "упадёт" в ответственный момент, и не будет засланного казачка (вируса/трояна) можно только маньяку "ретрограду" и тем кому это надо для хобби.

[Rst7 5]

1 hour ago, Alex77 said:

Мне просто очень интересно как винХР 32 уделывает наповал вин10 64. в такого рода вычислениях

Да никак не уделывает, не переживайте. Проигрывает безусловно. Причины я уже перечислил, и они совсем не в количестве доступного процессу ОЗУ, хотя в некоторых применениях это ох как важно.