Я, например, настоящая сова. Будучи предоставлен в отпуске самому себе, я перехожу строго на ночной образ жизни, ложась с восходом солнца и вставая во второй половине дня. Ночью тихо и свежо, самое прекрасное время для работы.
Эта проблема возникает независимо от перегрузки. Вопрос здесь в том, что делать первым - вычисление абсолютной величины или преобразование типа. А если смотреть глубже, то просто в том, как работает смена знака для целых чисел.
С восьмеричной перешли на шестнадцатеричную исключительно в связи с изобретением байта в IBM S/360. В связи с чем размеры адресуемых единиц памяти стали всегда кратны четырём разрядам, и очень редко – трём. Попробуйте-ка разбить на байты восьмеричное значение 32-разрядного слова 012345670123.
Рудиментом восьмеричной системы некоторое время оставалась архитектура PDP-11, в связи с тем, что там поля машинных команд функционально группировались по 3 бита.
Описывает и вызывает какие-то многочисленные текстовые экранные формы. Очень похоже на какой-то автоматически генерируемый код или близкую по сути вещь.
Фортран 2000+ – фактически совершенно другой язык, чем IV и 77. И по фактически используемому синтаксису, и по своему позиционированию. Но он тянет совместимость со старыми конструкциями, что хорошо с точки зрения использования легаси, но очень тяжело для современного первоначального обучения.
Лисп, который умеет в самомодифицирующийся код и строгую типизацию, может быть не менее эффективен даже в фортрановской нише
Если только фортрановский кодогенератор написать на Лиспе руками. Что в принципе, конечно, возможно, так как всю науку, как говорится, можно свести к S-выражениям, но практически в арсенале программиста этого нет.
Отделение компилятора от СУБД является определённым недостатком удобства и эффективности современных языков программирования, хотя увеличивает гибкость. Задумывалось изначально это всё не так, язык SQL разрабатывался в IBM фактически как подмножество PL/I.
В самом ТЗ от военщины ничего такого не было, поскольку там с Адой на конкурсе точно соревновался PL/I и, вроде, ещё Алгол-68, которые производными Паскаля безусловно не являются.
Даже в языке C/C++, где формально функции стандартной библиотеки не являются частью языка, оптимизирующий компилятор, тем не менее, осведомлён о семантике элементарных функций и компилирует прямо в арифметические машинные инструкции, а не в вызовы подпрограмм в соответствии с соглашениями о связях. Например, функция sqrt будет скомпилирована clang непосредственно в одну машинную инструкцию vsqrtsd. К сожалению, очень эффективные в системе команд SSE функции max и min в языке C не определены, а в языке С++ определены через уродливый макрос, поэтому компилируются в менее эффективные ветвления, а не более в эффективные vpmaxsd и vpminsd, но, во-первых, в предназначенном для эффективных расчётов Фортране такой проблемы нет, а во-вторых, всё равно даже встроенные в код ветвления эффективнее, чем вызов подпрограммы с теми же ветвлениями.
Что касается ассемблера, то многие библиотеки для численных расчётов включают ассемблерные функции. Все библиотеки Intel, например, реализованы в вычислительной части в машинном коде. Но и часть библиотек третьих авторов тоже.
Всё-таки Лисп в своей концепции довольно далёк от современного железа. Возможно, на IBM 704, где были знаменитые регистры CAR и CDR, тогдашний Лисп и более эффективно транслировался (хотя тогда, вроде, был только интерпретатор), но в современном железе всё заточено под векторно-конвейерные операции, и это совсем не то, что цепочки условных проходов по указателям в лисповских списках.
Другое дело, что Лисп обычно и применяют не там, где требуется высокая производительность любой ценой, а там, где нужно запрограммировать концептуально сложные, универсальные вещи.
Лисп прекрасен, но в смысле производительности не тянет.
Я как-то сравнил программы, выполняющие одинаковую обработку списков на Лиспе и на Фортране. Программа на Лиспе заняла 4 строчки, а на Фортране примерно 400. Но на Фортране она работала раз в 20 быстрее, чем в скомпилированном Лиспе. А если списки в Фортране заменить на массивы, то получалось ещё на порядок быстрее.
За счёт того, что встроенные операции оптимизируются компилятором в наиболее эффективный машинный код конкретного процессора. А внешняя библиотека, даже если её написать на ассемблере, на что редко кто заморочится, всё равно будет терять на выполнении соглашений о связях.
Тут ещё проблема в том, что реализация поверх языка неизбежно будет менее эффективна. А для таких программ, которые, например, раз в 10 суток сохраняют текущий результат расчёта для возможности перезапуска с этого места (реальный виденный мной пример из жизни) каждый процент производительности важен.
Разница в том, что сейчас по-настоящему солидно сделанных вещей вроде IBM PS/2 или Toyota Mark II просто не осталось в потребительском секторе. Да и в промышленном уже не очень.
А в том, что кроилово ведёт к попадалову, вы, конечно, правы. Но в 90-е годы можно было, например, купить видеокарту ATI, собранную белыми людьми в Канаде.
Я, например, настоящая сова. Будучи предоставлен в отпуске самому себе, я перехожу строго на ночной образ жизни, ложась с восходом солнца и вставая во второй половине дня. Ночью тихо и свежо, самое прекрасное время для работы.
В питоне для расчётов обычно используется numpy и его типы.
Эта проблема возникает независимо от перегрузки. Вопрос здесь в том, что делать первым - вычисление абсолютной величины или преобразование типа. А если смотреть глубже, то просто в том, как работает смена знака для целых чисел.
Вы неправильно прочли варианты.
В C++ fabs и sqrt перегружаются, но для пунктуальности исправил.
В <algorithm> было написано (по крайней мере, в 11-м clang) буквально следующее:
Хорошо, если это исправили.
Замысел-то понятен – обеспечить применимость ко всем упорядоченным классам. Но такой ценой это нафиг не упало.
С восьмеричной перешли на шестнадцатеричную исключительно в связи с изобретением байта в IBM S/360. В связи с чем размеры адресуемых единиц памяти стали всегда кратны четырём разрядам, и очень редко – трём. Попробуйте-ка разбить на байты восьмеричное значение 32-разрядного слова 012345670123.
Рудиментом восьмеричной системы некоторое время оставалась архитектура PDP-11, в связи с тем, что там поля машинных команд функционально группировались по 3 бита.
Описывает и вызывает какие-то многочисленные текстовые экранные формы. Очень похоже на какой-то автоматически генерируемый код или близкую по сути вещь.
Фортран 2000+ – фактически совершенно другой язык, чем IV и 77. И по фактически используемому синтаксису, и по своему позиционированию. Но он тянет совместимость со старыми конструкциями, что хорошо с точки зрения использования легаси, но очень тяжело для современного первоначального обучения.
Если только фортрановский кодогенератор написать на Лиспе руками. Что в принципе, конечно, возможно, так как всю науку, как говорится, можно свести к S-выражениям, но практически в арсенале программиста этого нет.
А в остальном я с Вами согласен.
Отделение компилятора от СУБД является определённым недостатком удобства и эффективности современных языков программирования, хотя увеличивает гибкость. Задумывалось изначально это всё не так, язык SQL разрабатывался в IBM фактически как подмножество PL/I.
В самом ТЗ от военщины ничего такого не было, поскольку там с Адой на конкурсе точно соревновался PL/I и, вроде, ещё Алгол-68, которые производными Паскаля безусловно не являются.
Даже в языке C/C++, где формально функции стандартной библиотеки не являются частью языка, оптимизирующий компилятор, тем не менее, осведомлён о семантике элементарных функций и компилирует прямо в арифметические машинные инструкции, а не в вызовы подпрограмм в соответствии с соглашениями о связях. Например, функция sqrt будет скомпилирована clang непосредственно в одну машинную инструкцию vsqrtsd. К сожалению, очень эффективные в системе команд SSE функции max и min в языке C не определены, а в языке С++ определены через уродливый макрос, поэтому компилируются в менее эффективные ветвления, а не более в эффективные vpmaxsd и vpminsd, но, во-первых, в предназначенном для эффективных расчётов Фортране такой проблемы нет, а во-вторых, всё равно даже встроенные в код ветвления эффективнее, чем вызов подпрограммы с теми же ветвлениями.
Что касается ассемблера, то многие библиотеки для численных расчётов включают ассемблерные функции. Все библиотеки Intel, например, реализованы в вычислительной части в машинном коде. Но и часть библиотек третьих авторов тоже.
Всё-таки Лисп в своей концепции довольно далёк от современного железа. Возможно, на IBM 704, где были знаменитые регистры CAR и CDR, тогдашний Лисп и более эффективно транслировался (хотя тогда, вроде, был только интерпретатор), но в современном железе всё заточено под векторно-конвейерные операции, и это совсем не то, что цепочки условных проходов по указателям в лисповских списках.
Другое дело, что Лисп обычно и применяют не там, где требуется высокая производительность любой ценой, а там, где нужно запрограммировать концептуально сложные, универсальные вещи.
Лисп прекрасен, но в смысле производительности не тянет.
Я как-то сравнил программы, выполняющие одинаковую обработку списков на Лиспе и на Фортране. Программа на Лиспе заняла 4 строчки, а на Фортране примерно 400. Но на Фортране она работала раз в 20 быстрее, чем в скомпилированном Лиспе. А если списки в Фортране заменить на массивы, то получалось ещё на порядок быстрее.
За счёт того, что встроенные операции оптимизируются компилятором в наиболее эффективный машинный код конкретного процессора. А внешняя библиотека, даже если её написать на ассемблере, на что редко кто заморочится, всё равно будет терять на выполнении соглашений о связях.
Плюс оптимизация арифметических выражений
Тут ещё проблема в том, что реализация поверх языка неизбежно будет менее эффективна. А для таких программ, которые, например, раз в 10 суток сохраняют текущий результат расчёта для возможности перезапуска с этого места (реальный виденный мной пример из жизни) каждый процент производительности важен.
Вряд ли это верно. Паскаль того времени задумывался как очень компактный язык, а Ада имеет монструозный синтаксис и семантику.
Когда люди действительно жили охотой на зайцев, никто ружья под конкретного человека не делал. Их передавали по наследству.
Разница в том, что сейчас по-настоящему солидно сделанных вещей вроде IBM PS/2 или Toyota Mark II просто не осталось в потребительском секторе. Да и в промышленном уже не очень.
А в том, что кроилово ведёт к попадалову, вы, конечно, правы. Но в 90-е годы можно было, например, купить видеокарту ATI, собранную белыми людьми в Канаде.