IT в России и мире в реалиях мирового кризиса

Цитата: mse от 30.04.2021 13:04:51Да банкиры правы: зачем списывать в утиль программы, которые уже лет 50 вылизывали? И программ этих не 10-20, а тыщщи и десятки тыщ. И размеры у них конские. И поддержка уже, наверняка, не вполне соображает, что там в глубине глубин. К тому-же кто-кто, а Кобол в защите не нуждается. Он стабильно в десятке наиболее актуальных языков.
"Солнце всходит? Заходит? Не трогай, сломаешь."

   
Абсолютно согласен.
Вот только даже зная что-то о Коболе (редкостная окаменелость!), делать выводы о современных архитектурах — это кружковский зашквар...

Цитата: mse от 30.04.2021 13:04:51Да банкиры правы: зачем списывать в утиль программы, которые уже лет 50 вылизывали? И программ этих не 10-20, а тыщщи и десятки тыщ. И размеры у них конские. И поддержка уже, наверняка, не вполне соображает, что там в глубине глубин. К тому-же кто-кто, а Кобол в защите не нуждается. Он стабильно в десятке наиболее актуальных языков.
"Солнце всходит? Заходит? Не трогай, сломаешь."

Тем более подо что переписывать? х86/amd64 на сегодня такая же виртуалка, крутящаяся над реальными архитектурами процессоров, за которыми я так уже давно соскучился следить. Кто знает, сколько там физических регистров общего назначения? Последняя информация, которая мне попадалась, больше сотни, прозрачно для программиста подменяющих друг друга. 

Цитата: Longspig от 29.04.2021 21:27:41"Относительной" точность в FPU становится лишь выше значения 2**64-1 (знак забирает разряд из поля порядка и тут не участвует). Но операции целочисленого сохранения всегда знаковые, так что разряд теряем (2**63-1). До этого предела, точность представления любого целого числа в FPU абсолютная.
Прекрасно работал с целыми 64-битными числами через FPU.

Вы просто не понимаете, что такое "абсолютная точность" и что такое "относительная точность", а также что такое "логарифмическая равномерность".
Вещественное число за редчайшим исключением (как говорят математики, "везде, за исключением выколотых точек") не может быть представлено в формате IEEE 754 точно. Это называется "погрешность представления".
У любого вещественного числа есть два ближайших к нему числа, которые точно представимы в формате IEEE 754 – одно меньше, другое больше.
Это имеет место для представления вещественных чисел по любому основанию в форме мантиссы и порядка.
Разность между этими двумя рядом расположенными числами тем меньше, чем ближе к нулю они расположены. Зато их отношение остается постоянным для всего диапазона. Это называется "логарифмическая равномерность представления вещественных чисел в форме с мантиссой и порядком".
Для целых, в отличие от вещественных, какие вы бы не брали рядом расположенные числа, у них разность будет постоянна, а отношение тем ближе к единице, чем числа больше. Это же справедливо и для формата с фиксированной запятой, поскольку она есть не что иное, как масштабированное целое.
Если сходу не понятно, то просто возьмите два любых числа в формате IEEE 754 и помасштабируйте, меняя порядок. Разность между ними будет различной, а отношение останется без изменения. Это и называется относительной точностью. По аналогии с погрешностью измерений. Только здесь погрешность представления.
...
Окуда вы взяли "2**64-1", не понятно. Это число никакого отношения к FPU не имеет вообще. Вот из IEEE 754-2008 таблица с параметрами


И еще – FPU не работает с целыми. Просто почитайте "Intel 64 and IA-32 Architectures Software Developer's Manual" – там все расписано. Может загружать целое, при этом  оно преобразуется во внутренний формат и все операции выполняются как с плавающими. Это значит, что при арифметических операциях Вы получите результат, отличный от того, что получили бы на CPU. Будете делить 5 на 2 и получите либо 2, либо 3, в зависимости от того, как будет установлено округление в RC. Вот цитата:

"The x87 FPU recognizes and operates on the following seven data types: single-precision floating point, double-precision floating point, double extended-precision floating point, signed word integer, signed doubleword integer, signed quadword integer, and packed BCD decimal integers.
With the exception of the 80-bit double extended-precision floating-point format, all of these data types exist in memory only. When they are loaded into x87 FPU data registers, they are converted into double extended-precision floating-point format and operated on in that format.

У меня складывается впечатление, что Вы вообще никогда с плавающей запятой не работали. Разве что в питоне или матпакете.

Цитата: mse от 30.04.2021 00:53:54Чо вы несёте? Система команд, это логические и арифметические операццыи над данными в регистрах и памяти. Вся это сегментная и косвенно-регистрово-индексная адресаццыи, это только обмазка вокруг арифметики и логики. А тонкости архитектуры способен оценить только системщик. Прикладнику дали компилятор и насрать ему, на чом он работает, на ИБМ360 или на каком х86.

Это не тонкости архитектуры, а обыденка для программиста. Методы адресации памяти и расположение операндов – это основы.

Цитата: adolfus от 02.05.2021 05:04:24...
Окуда вы взяли "2**64-1", не понятно. Это число никакого отношения к FPU не имеет вообще. Вот из IEEE 754-2008 таблица с параметрами


И еще – FPU не работает с целыми. Просто почитайте "Intel 64 and IA-32 Architectures Software Developer's Manual" – там все расписано.

Сами же говорили, FPU x387 не соответствует IEEE-xxx т.к. работает с 80-битными числами, где 64 разрядов мантисса и 14 разрядов порядок (два разряда на знаки) - называется "расширеный формат". И работал я в основном на Ассемблере, особенно когда писал  отладчик для 32-битного ДОС. И работа с 64-битными целыми мне иногда требовалась. И проверял я FPU на потерю точности неединожды, т.к. мне терять даже один разряд было категорически запрещено. А дальше - дело компилятора, языка высокого уровня, обеспечить "внешний интерфейс" в соответствие с IEEE, но внутрение операции с использованием всех возможностей FPU, т.е. 80-битные операнды. Встроеное число Пи,  внутренее представление вообще имеет 66 разрядов, но "наружу" видны лишь 64, и нормально все работает.
Есть особенно "вкусные команды" FBSTP/FBLD. Они "перегоняют " десятичные упакованые числа в/из памяти в регистры FPU. В памяти формат тоже 10-байтный. 18 используемых тетрад дают столько же десятичных знаков. Особо отмечается в документации - операции с целыми числами происходят без потери точности (весь десятичный ввод/вывод я делал этими командами).
...
Если есть у кого желание "пощупать", могу дать образ этой среды. Т.е. комп превращаетрся по сути в простой однозадачный контроллер. Вся память (сколько ее отдал чипсет) в распоряжении программиста. "Погулять" пошагово отладчиком по программе в "нулевом кольце", когда никто и ничто не мешает и не лезет со своими ограничениями.
Увы, дело вначале муторное. Нужен довольно старый комп  с ДОС (чипсет не выше ICH7, где работа с дисками в Compatible mode). Да еще живой флоппи диск (надо фиксировать состояние памяти на момент загрузки, т.к. ДОС потом подменяет вектора. Делается один раз).
Всё никак не доведу до минимального приличия, чтобы выложить.
Впрочем, сам ДОС даже не нужен. Могу дать прямо с образом, для вписываняи на диск. Но диск отдельный да, нужен.

Цитата: mse от 02.05.2021 14:58:07Яснепень, что основы. Для системщика. А прикладнику достаточно ресурсов языка. Он работает на абстрактной машине, которая описывается выражениями языка. Пейсатель "ХYйло, Ворд" на каком Питоне или Жабе, может не знать, сколькиразрядный процессор в его компутере, какой видеочип показывает и где его креатифф хранится. Когда я пишу на Ц под МИПС, меня совершенно не парит, что у них нет признака переноса, половины разнообразия сдвигов и прочее, кривое и косое. И речь имана об то, что если у богатеньких буратин есть формализованный алгоритм подсчота золотых, он может быть исполнен хоть на 8разрядной пукалке.

На C вообще нет доступа к биту переноса и сдвига только два типа. Если нужны биты переноса, и прочие, что выставляются по результату выполнения инструкции, нужно писать на ассемблере. Это не так сложно, как кажется.
Что касается подсчета золотых на 8-разрядной пукалке, то, к сожалению, скорость изменения количества этих золотых на пару порядков будет больше скорости подсчета. Соответственно, подсчет это будет никому не нужен. Есть понятие "реальное время", и оно имеет смысл, в том числе, для экономической вселенной.

Цитата: mse от 02.05.2021 20:17:27Ну я каг-бы в курсе про перенос. Но речь-то не о переносе. В языках перенос вообще не нужен, как правило. Ну и про 8 разрядов из той-же оперы. Речь не про разряды, а про алгоритмы. Кстате, клевещут, что у Visa, в среднем, 1700 транзакций в секунду. Понятно, что каждая из них достаточно объёмная и не столько вычислительная работа, сколько работа в базе данных. Но вычислитель на 1700 даблов/с, вполне реализуем и на каком толклвом 8р, не говоря о 16р.

Если бы все было так просто, то IBM не выпускала бы мэйнфреймы и сервера транзакций для них, а пересела бы на x86_64 и продвигала бы дибиту или информикс. Однако она продвигает z/OS и сервера CICS, которым сегодня столько, сколько и коболу.
Основная проблема цифровых вычислительных машин  – это не быстродействие процессоров, а возможности по доставке из хранилища в процессор данных и выводу их оттуда назад в хранилище. Собственно, транзакция именно из этого и состоит чуть менее, чем полностью. Так что никакие 8-и и 16-разрядные системы, как бы здорово они не считали даблы, здесь не играют. На поприще железа под сервера транзакций в классе x86_64 лет пять-семь назад пыталась играть Supermicro с InfiniBand и FiberChan на доступе к хранилищу. Вроде как даже участвовали в тендере на лондонской бирже.

Цитата: Y от 04.05.2021 17:17:43Ты некомпетентен даже в том, в чем якобы специалист.
Современный банк это всегда java/oracle, забудь про IBM, это монстры прошлого.

Так может быть в России бо большинство банков появилось относительно недавно, а в мире у многих банков (не буду говорить все) основные приложения написаны когда ни java ни oracle ещё и в проекте не было.

Цитата: mse от 04.05.2021 18:15:52Не... В таких вещах народ не рискует. Есть гарантийный срок службы сервера-кластера, по истечению - на свалку. Хотя он, вполне себе, готов работать ещо лет 20.

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

Цитата: Y от 04.05.2021 20:01:31Разве только про Россию речь? Сотни банков по всему миру.
Например, все основные процессинги.

Тогда ваше утверждение не верно по крайне мере в отношении банков С. Америки, здесь IBM никуда не делся.

Цитата: mse от 04.05.2021 15:06:10Блин. Чо вы уводите разговор в сторону? ИБМ уже много чего двигала и не всё двинулось, как она хотела. И, ессно, дело не в разрядности, как вы изначально утверждали и не в виртуозном использовании эксепшынов, а в каких-то менее заметных тонкостях архитектуры. Причом, скорее всего, дело просто в каких-то вопросах, не имеющих отношения к технике и программированию, вообще.

Это вы уводите в сторону. Изначально речь шла о том, что вселенная x86_64 остывает, и что ей на смену пришли более продвинутые решения, в частности микропроцессор z/15, поддерживающий однородную память. Основная проблема x 86_64 в том, что она не в состоянии обеспечить за вменяемые деньги однородный доступ хотя бы к одному терабайту памяти. Собственно, таких систем на базе x86_64 и нет. Удел x86_64 – канцелярские персоналки. С чего начали, на том и закончат.

Цитата: Y от 04.05.2021 17:17:43Ты некомпетентен даже в том, в чем якобы специалист.
Современный банк это всегда java/oracle, забудь про IBM, это монстры прошлого.

Java – это всего лишь язык программирования среди дюжины других. Своей популярнностью обязан, отнюдь, не ораклу, а именно IBM, которая стала ее использовать на своих платформах задолго до того, как об оракле вообще услышали.
Оракл? Единственное, что у них есть приличного, это патчи в линуковое ядро. База данных – редкостное тормозное говно, изолированное от пользователей толстым и вязким слоем SQL и NoSQL-веб-костылями. На одной и той же платформе  дибиту и информикс дают ораклу сто очков вперед как по производительности, так и по удобству использования программистами и администраторами. По сравнению с базами данных IBM, оракле – это  кучка кирпичей, из которых еще нужно умудриться сложить что-то надежно работающее. Причем в условиях отсутствия нормальных инструментов.

Цитата: Y от 04.05.2021 22:37:13Да, в юсе многие на ibm, но их системы уже десятки лет не меняются.
Это тот случай, когда сохраняется не "отлаженный, стабильный код", а сохраняется множество багов и уязвимостей,1 и они не исправляются годами.

Нет там никаких багов – работает все десятилетиями и не глючит. Есть языки, не которых написать кривую программу можно только специально, но и то не всегда. Эти языки создавались не для того, чтобы облегчить жизнь начинающему программисту, а чтобы был способ строгого математического доказательства правильности программы. Это языки на обрыве складки Уитни.
Сегодня многие, кто себя считает программистом, никогда не изучали ни теории компиляторов, ни методов доказательства правильности программ. Все, чем они пользуются, это фреймворки, написанные на фреймвоках (тут рекурсия). Поэтому сайты вокзалов, аэропортов, аптек, библиотек, интернет-магазинов и прочих информационных ресурсов такие убогие. Больше похожи на сайты собачьих парикмахерских.


 

Цитата: adolfus от 05.05.2021 00:35:44Java – это всего лишь язык программирования среди дюжины других. Своей популярнностью обязан, отнюдь, не ораклу, а именно IBM, которая стала ее использовать на своих платформах задолго до того, как об оракле вообще услышали.
Оракл? Единственное, что у них есть приличного, это патчи в линуковое ядро. База данных – редкостное тормозное говно, изолированное от пользователей толстым и вязким слоем SQL и NoSQL-веб-костылями. На одной и той же платформе  дибиту и информикс дают ораклу сто очков вперед как по производительности, так и по удобству использования программистами и администраторами. По сравнению с базами данных IBM, оракле – это  кучка кирпичей, из которых еще нужно умудриться сложить что-то надежно работающее. Причем в условиях отсутствия нормальных инструментов.

Э... я так и не врубился в суть спора. 
Первоначально я думал что речь в итоге об RISC и CISC, но все более убеждаюсь что речь об верованиях сиречь религии.
Те мейнфреймы что были изначально, по архитектуре отличаются от мейнфреймов появившихся в 90-е...., ну место суперкомпьютеров с конца 20 века и до сего дня занимают блейдовые решения
В принципе какая разница для самой ЭВМ, на каком языке высокого уровня написана программа, в итоге она через стадию превращений оказывается банальным двоичным кодом.
Разница только для решаемых задач и программистов, ну никто не будет сегодня писать управление техпроцессами на фортране, а на ассемблере сложные математические вычисления.
То же и касается кобола, который оказплся идеально заточен под решение экономических и финансовых задач. А на какой платформе, это вопрос наличия и качества транслятора. 
Вот у нас на ЕС ЭВМ лучше был транслятор с PL/1 и именно его использовали как базовый, для создания заводской АСУ. Однако не возбранялись для решения локальных задач иные языки, но чтобы с комментариями и разрисованными алгоритмами. (Одно из важнейших условий, чтобы в коде мог разобраться "любой" программист, участник проекта.) 
У моей группы например, основные ассемблер, паскаль, реляционная СУБД и фортран для общения СУБД с паскалем. 
Была и работа в двоичных кодах. 
К примеру для электроники С5-02 писали и отлаживали на псевдокоде и эмуляции на ЕС, а затем в виде двоичных кодов загоняли в С5....
И именно  поэтому мне непонятна такая агрессивная реакция на Oracl. Это же СУБД, а на каком языке для неё писать дело второе. Из реляционных баз, я просто не знаю более развитой и быстрой СУБЛ общего назначения, особенно на громадных объемах. Не если писать специализированную под конкретную задачу, тогда может быть, но это же исключение. 
А если Вам больше нравятся иерархические или сетевые модели, дело как говориться хозяйское, так у них у каждой полно своих недостатков и преимуществ по сравнению с реляционной, но последняя в любых раскладах и проще и гибче, и менее требовательна к постановочной части....

Цитата: mse от 05.05.2021 01:42:274 TB ECC REG DDR4 Походу, комментарии излишни...

Оно не однородное. Там нума во все дыры поля. Я правда эпиков последних не щупал, но оченьма подозреваю, что амуди в своем любимом репертуаре, расширенном и углубленном. Где у штеудов две ноды нумовские (по одной на сокет) у амуди бывало и 4 (по 2 на сокет, отчего-то).

И это, я  уже с неделю собираюсь спросить adolfus'a, а на кой ему теребайт ажно, однородный? Шо он с ним таким делать собрался?

Цитата: qurvax от 07.05.2021 13:10:16Оно не однородное. Там нума во все дыры поля. Я правда эпиков последних не щупал, но оченьма подозреваю, что амуди в своем любимом репертуаре, расширенном и углубленном. Где у штеудов две ноды нумовские (по одной на сокет) у амуди бывало и 4 (по 2 на сокет, отчего-то).

И это, я  уже с неделю собираюсь спросить adolfus'a, а на кой ему теребайт ажно, однородный? Шо он с ним таким делать собрался?

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

Цитата: adolfus от 08.05.2021 01:04:03Отвечаю. Считать трехмерную нестационарную задачу на достаточно большой сетке. Явление, к сожалению, мультимасштабное и хуже того, не локальное. И нужен не один терабайт, а штук сорок на первое время – это позволит оценить необходимую степень мультимасштабности. Стандартный способ – измельчаем сетку до тех пор, пока результаты не стабилизируются, т.е. пока мелкомасштабные эффекты не перестанут влиять на общую картину.

Нда, мсье определенно знает толк... Я нихрена не понял, но звучит умно.

0:00-2:20 - Политика и деглоблизация
2:20-9:21- Создание процессоров Эльбрус и сфера использования
9:21-13:22 - Первый в мире многоядерный "компьютер"
13:24-18:45 - Роль западных партнёров в формировании высокотехнологичных компаний в РФ
18:48-26:14 - Тех.процесс и производство процессоров Эльбрус
26:15-28:17 - Инфраструктура и карьера в компании МЦСТ
28:19-32:0 - Проектирование процессоров Эльбрус
32:02-36:44 - Роль специалистов МЦСТ в компании Intel
36:44-44:27 - Поддержка МЦСТ государством, "массовость производства" и создание рабочих мест
44:29-53:32 - Особенность и безопасность архитектуры Эльбрус
53:33-59:54 - верификация прототипов, оптимизация софта под процессоры Эльбрус, переходим на Linux
59:54-1:05:14 - Операционная система Эльбрус
1:05:16-1:14:03 -Виртуализация сторонних приложений, особенности программирования, перспективы разработки видеочипов
1:14:04-1:18:35 - "Кадры решают всё", финансирование и желание зарубежных гигантов купить разработки российских специалистов
1:18:36 - 1:29:30 Видеокарты, с которыми работают процессоры Эльбрус, визия и маркетинг развития компании МЦСТ
1:29:30-1:42:26 - адаптирование производства под потребности рынка процессоров, разгон процессоров, эксплойты и превенция уязвимостей, написание кода, тензорные ядра
1:42:26-1:46:48 - Регистры общего назначения и "проектирование низкого уровня"
1:46:49-1:55:13 - Перевод вычислений на аппаратные части, встроенный компилятор, превосходство Эльбрус над Intel
1:55:13-2:03:22 - Лимит тех.процесса, видеокарты от компании МЦСТ, реалии производства процессоров в России, шаги на встречу обычному потребителю

Цитата: wwm от 19.05.2021 01:03:050:00-2:20 - Политика и деглоблизация
2:20-9:21- Создание процессоров Эльбрус и сфера использования
9:21-13:22 - Первый в мире многоядерный "компьютер"
13:24-18:45 - Роль западных партнёров в формировании высокотехнологичных компаний в РФ
18:48-26:14 - Тех.процесс и производство процессоров Эльбрус
26:15-28:17 - Инфраструктура и карьера в компании МЦСТ
28:19-32:0 - Проектирование процессоров Эльбрус
32:02-36:44 - Роль специалистов МЦСТ в компании Intel
36:44-44:27 - Поддержка МЦСТ государством, "массовость производства" и создание рабочих мест
44:29-53:32 - Особенность и безопасность архитектуры Эльбрус
53:33-59:54 - верификация прототипов, оптимизация софта под процессоры Эльбрус, переходим на Linux
59:54-1:05:14 - Операционная система Эльбрус
1:05:16-1:14:03 -Виртуализация сторонних приложений, особенности программирования, перспективы разработки видеочипов
1:14:04-1:18:35 - "Кадры решают всё", финансирование и желание зарубежных гигантов купить разработки российских специалистов
1:18:36 - 1:29:30 Видеокарты, с которыми работают процессоры Эльбрус, визия и маркетинг развития компании МЦСТ
1:29:30-1:42:26 - адаптирование производства под потребности рынка процессоров, разгон процессоров, эксплойты и превенция уязвимостей, написание кода, тензорные ядра
1:42:26-1:46:48 - Регистры общего назначения и "проектирование низкого уровня"
1:46:49-1:55:13 - Перевод вычислений на аппаратные части, встроенный компилятор, превосходство Эльбрус над Intel
1:55:13-2:03:22 - Лимит тех.процесса, видеокарты от компании МЦСТ, реалии производства процессоров в России, шаги на встречу обычному потребителю

Один только документ "Intel 64 and IA-32 Architectures Software Developer's Manuals. 325462-074US (April 2021).pdf" занимает 5106 страниц.
Сколько страниц занимает аналогичный документ на Эльбрус  и где его можно скачать? Без документов такого рода бессмысленно вообще обсуждать какой-либо процессор.

Цитата: adolfus от 21.05.2021 02:18:13Один только документ "Intel 64 and IA-32 Architectures Software Developer's Manuals. 325462-074US (April 2021).pdf" занимает 5106 страниц.
Сколько страниц занимает аналогичный документ на Эльбрус  и где его можно скачать? Без документов такого рода бессмысленно вообще обсуждать какой-либо процессор.

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