Мир зависит от кода 60-летней давности, о котором больше никто не знает

Ну, положим, машинный код состоит из байтов. Иногда я называю исполняемые файлы исполняемыми бинарниками. Впрочем неважно.

Насчёт платформы не спорю. Но я сильно сомневаюсь, что на одной и той же платформе исполняемый файл, скомпилированный из исходника на тех же "плюсах", будет как-то сильно хуже исполняемого файла, скомпилированного из исходника на COBOL, при условии, что оба исходника реализуют один и тот же алгоритм. Может быть, "плюсы" потеряют буквально десяток-другой процессорных тактов в производительности. Но при нынешних мощностях, IMHO, это несущественно даже для критичных с точки зрения производительности систем.

все люди одинаковые. две руки две ноги и голова. никакого разнообразия.

Чатгпт в критическую инфраструктуру ... превосходно.

Размещено через приложение ЯПлакалъ

А таблицу умножения невозможно выучить в принципе, она древнее Вавилона.

Не, он просто собирается на ноль поделить если что.

До сих пор на ХР сижу.. Только яйца крепче!

программисты могут обьяснить, почему на спектруме 48к я играл легко и с удовольствием, а теперь надо железо каждые полгода обновлять? мне графика нафиг.мне смысл главное! болдердаш сейчас наверное сервер снимать уже надо?

Мне это тоже было любопытно лет 30 назад, когда я подумывал перейти с Паскаля на Си. Простейший код вывода того самого "Hello world". Отличался дичайше.
Потом попробовал простейшие циклы без вывода данных (посмотреть, какие машинные коды герируются для чисто математических операций). Разница тоже была огромной.
И еще существенней она стала, когда я написал тот же цикл непосредственно машинными кодами. То, что скомпилированные программы делали около минуты, самописный машинный код делал за долю секунды.
Единственный путь приблизиться к эффективности машинного кода - это ассемблер. Любой язык более высокого уровня будет намного менее эффективен, ЕСЛИ только он не заточен под определенную сферу, и определенные функции в нем реализованы программистами на уровне хотя бы ассемблера, а не высокоуровневых раздутых библиотек.
Вот поэтому мне и кажется, что специальный язык для бизнес-задач вполне может оказаться гораздо эффективнее для решения этих задач, чем современные универсальные языки программирования.

Можете огласить предметную область и примерную сложность алгоритма, где ВАШ ассемблерный код исполняется доли секунды, а "скомпилированный" (я полагаю, что нормально написанный на внятном ЯВУ, и скомпилированный профессиональным компилятором)- минутами.
И C и плюсы позволяют писать код, вполне себе эффективный. И loop unroll, и инлайнинг, и исключение неиспользуемого кода, и регистровая оптимизация- всё это уже лет как 15 вполне работает.

Размещено через приложение ЯПлакалъ

Ох бро, чето ты преувеличиваешь. Примеры можно?

Видимо программа была каким-то образом оптимизирована под принтер на лпт порту, или кассу с компортом, или какое другое периферийное устройство. Кто писал на фокспро, уже на пенсии, а молодежь кроме как мышкой кликать ничему не научилась.

Есть знакомая тётка за 60, она этот Кобол знает и писала когда-то на нем - надо сказать ей что мильёны может рубить если вспомнит это дело и к амерам переедет!

нормально всё работает, решений множество, от софта, до создания кастомного local port штатными средствами оси.
работал как-то в одной древней конторе, у них софт еще на клиппере написан, пытались перейти на 1С но по факту оказалось что 1С работает на порядок медленнее чем их старьё.

Готов на хтмл переписать
Бейсик уже подзабылся

Это сообщение отредактировал DMDK - 5.12.2023 - 10:19

Я проверял на двух вещах.
1. Вложенные циклы с прибавлением единички к значению переменной.
Точных цифр уже не вспомню.
2. Попиксельное заполнение экрана. Тут разница была визуально наглядной. Скомпилированная программа реально заполняла так, что я видел, как бежали строки пикселей. Машинный код просто менял цвет экрана мгновенно, хотя написан был именно как попиксельное заполнение.
Я ж упоминал, что дело было около 30 лет назад, когда я в универе учился. Возможно, сейчас все иначе. Но я уже давно не программист, так что просто предполагаю на основе прошлого опыта, что узко специализированное должно быть эффективнее продукта общего назначения.

P.S. Насчет минуты на заполнение может и преувеличил. Может быть секунд 3-5. Но в любом случае разница с моментальным изменением цвета была настолько впечатляющей, что запомнилась мне навсегда.

Это сообщение отредактировал Frenger - 5.12.2023 - 11:03

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

Все новое в последние лет наверное 15 в здравом уме никто на коболе не пишет. А старое работает ровно до тех пор, пока в него не требуется доработки вносить.

1. Современный компилятор скорее всего выкинет оба цикла и присвоит конечный результат.
2. Тоже разницы не будет, упрется в производительность видеопамяти.

как хобби я все еще умею и помню руками писать на ассемблере.
Но в продакшене за последние 25 лет применял всего раза два

1) руками с использованием всяких SSE алгоритм Тарьяна, предварительно набросанный на С++ и допиленный для решения логистических задач по очень объемным картам из openstreetmap.
Ускорение раза в 3-4. Но это все x86-64 с его костыльной системой команд, под которую компиляторам сложно оптимизировать автоматически.
Под Arm система команд простая и красивая, и выиграть у компилятора руками больше чем 1.5х скорости вряд ли получится. Очень редко больше, если в какой-то критичной функции получилось все впихать в регистры там, где компилятор использовал стек.
Под MIPS компилятор скорее всего будет лучше человека, там мозголомная система команд, но при этом удобная компиляторам.

2) при впихивании веб-сервера для настроек железки в эту железку на stm32 с 16кб оперативки и 128кб флеш (реально меньше, и большая часть уже занята под основной функционал железки). Там был важен объем кода и используемой памяти, а не скорость, вариант чисто на С не очень впихивался.

Но это все редкая экзотика, на практике сегодня большая часть задач пишется на C#, Pуthon и Java, вопросы производительности решаются покупкой дополнительных ресурсов в кубернетсе. Еще процедурки на Oracle/Posgres PL/SQL. Cobol за последние 25 лет вживую не видел нигде, и в банках в том числе.

Может там просто сертифицирован не сам алгоритм, который можно на любом языке повторить, а сертифицирована программа, написанная сто лет назад. Что-то типа цифровой подписи, или верификации транзакции. А уже вокруг этого программного модуля всякая обвязка в виде банковского ПО.
И что бы теперь сменить этот клочок кода, требуется провести колоссальную работу юристам, программистам, да и много кому еще.

Это сообщение отредактировал mangus - 5.12.2023 - 11:46

Пока все и так работает - никто на переписывание ни копейки не выделит.
А вот как перестает работать - может оказаться проще внедрить новую систему, чем поддерживать костыли 30летней давности, у которых могли и исходные коды в прошлом веке потеряться. Незнание кобола наименьшая проблема, его то как раз можно выучить.

Навскидку знаю одну программу, которую реально поддерживают и патчат больше 45 лет, это прошивка вояджеров)

Согласен))

Размещено через приложение ЯПлакалъ

Потому всякая хуйня и тормозит на хорошем железе, что рождаются такие инженеры. Выблядки.

Размещено через приложение ЯПлакалъ

Под ESC вообще-то у мну были всякие отдельные библиотечки или PRG-шники однажды написанные и таскаемые из задачи в задачу, которые прилинковывались к проге или проекту, ну а там да, самый смак был, но он одноразовый, потом просто в конфиге указываешь, чо у тя за принтер и вперед с песнЯми. Рядовая задача и никакой особой ебатни.

До сих пор поддерживаю программы написанные на этих языках. Клиппер не очень удобен, так как нет отладчика. Приходится ставить точки останова в предполагаемых местах ошибок и смотреть результат. ФоксПро классный язык для работы с базами и таблицами. Работает без прокладок ОДБС напрямую. Как и Клиппер.

Это сообщение отредактировал Michail007 - 11.12.2023 - 11:55