Выход KDE Plasma 6.0 запланирован на 28 февраля 2024 года

Там сравнимые величины. Выигрыш в скорости достигается, когда C++ превращается в ассемблер.

Выигрыш в скорости достигается, потому что сишка логически близка к ассемблеру

К каком ассемблеру? К ассемблеру PDP-11?

там разница в 4 раза, чувак.

И к 68k )

Тебя не смущает тот факт, что для достижения этой разницы ты должен прибегать к платформозависимым расширениям языка, от чего код превращается в тыкву при попытке выполнить его на чем-нибудь еще?

Тебя не смущает тот факт, что для достижения этой разницы ты должен прибегать к платформозависимым расширениям языка, от чего код превращается в тыкву при попытке выполнить его на чем-нибудь еще?

Ты сам написал, что от языка производительность не зависит. Хочешь сказать, всё таки зависит?

Вообще то, он все правильно написал, от самого языка производительность напрямую не зависит.
Все зависит от реализации(компиляторы/интерпретаторы) и платформы(библиотеки/среды исполнения).
Да, между ними может быть существенная разница, но это ничто по сравнению с тем, чего можно добиться более оптимальной архитектурой/алгоритмом.
Речь идет естественно о комплексных проектах, в элементарных это не нужно.

Да, между ними может быть существенная разница, но это ничто по сравнению с тем, чего можно добиться более оптимальной архитектурой/алгоритмом.

Тогда почему жаба так тормозит?

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

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

Потому что она интерпретируемая и с GC.

Да никто не говорит, что алгоритмы не нужны. Нужны. Просто если один и тот же алгоритм написать на копилируемом языке и на интерпретируемом, то у последнего нет шансов обогнать (или хотя бы догнать) первый.

Я понимаю, но я имел ввиду серверные системы, где взаимодействуют десятки компонентов, зачастую написанные разными исполнителями.
Сишечке там нет места.

Просто если один и тот же алгоритм написать на копилируемом языке и на интерпретируемом, то у последнего нет шансов обогнать (или хотя бы догнать) первый.

Тут все зависит от сложности архитектуры/алгоритма, в простых так и есть, но в более сложных случаях, ты просто не сможешь написать это на своем «копилируемом языке».

она интерпретируемая

Нет. Там JIT.

GC

Иииии? Там чувак выше писал, что все эти GC и JIT не должны влиять. Я с его тезисом спорю. Так-то я знаю прекрасно, почему жаба тормозит.

Что это я не смогу написать? Если язык умеет складывать, вычитать, переходить по адресу и сравнивать, то на нем можно написать все что угодно. А возможности C сильно больше, не говоря о возможностях C++. И что-то я сильно сомневаюсь, что есть какой-то более сложный алгоритм, чем компиляция программы на C++. А компиляторы С++ написаны на С++ (например https://gcc.gnu.org).

Нет. Там JIT.

Нет. javac транслирует программу на Java в байт-код JVM, которая является интерпретатором.

Кстати, из-за того, что в Java нет UB, оптимизатор компилятора не может проводить очень многие оптимизации.

GC

Иииии? Там чувак выше писал, что все эти GC и JIT не должны влиять. Я с его тезисом спорю. Так-то я знаю прекрасно, почему жаба тормозит.

Программа работала-работала, потом память кончилась. Интерпретатор остановил программу, обошел все ссылки, выявил неиспользуемые объекты, дефрагментировал память, возобновил интерпретацию. В смысле не влияет???

Википедия не согласна:

JIT используется в реализациях Java (JRE), JavaScript, .NET Framework, в одной из реализаций Python — PyPy.[3] Существующие наиболее распространённые интерпретаторы языков PHP, Ruby, Perl, Python и им подобных имеют ограниченные или неполные JIT.

Кстати, тут не упомянут еще один notable проект - luajit.

Ну формально можно сразу java, минуя javac, скормить программу, но тогда он будет ее транслировать в байт-код «на лету» и это будет еще медленнее, причем сильно.

Ну формально можно сразуjava, минуяjavac, скормить программу, но тогда он будет ее транслировать в байт-код «на лету» и это будет еще медленнее, причем сильно.

Что ты несёшь? JVM содержит JIT, который транслирует байт-код в бинарный код на лету, кэширует его и впоследствие исполняет сразу бинарный код.

Кстати, из-за того, что в Java нет UB, оптимизатор компилятора не может проводить очень многие оптимизации.

Какие, например?

Программа работала-работала, потом память кончилась. Интерпретатор остановил программу, обошел все ссылки, выявил неиспользуемые объекты, дефрагментировал память, возобновил интерпретацию. В смысле не влияет???

Спрашивай у LongLiveUbuntu, не у меня. Но в тех бенчмарках и правда не влияет, потому что GC не успевает запуститься.

К слову, твоё описание работы GC устарело лет на 10-15.

Программа работала-работала, потом память кончилась

Программист-рукожоп устроил циклические зависимости между ссылками на объекты и утечку, а виноват ЯП. Ага.

что в Java нет UB

Слава тебе, боже, что она не плюсы.

Что ты несёшь? JVM содержит JIT, который транслирует байт-код в бинарный код на лету, кэширует его и впоследствие исполняет сразу бинарный код.

Да? И как тогда работает NullPointerException? Если выполнить операцию разыменования на 0, то это UB.

Какие, например?

Да даже простейший цикл Java оптимизировать не может.

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

Руками ограничь память. Точно не помню, но ключи назывались вроде -Xmx и -Xms.

Я бы так не радовался. Интерпретатор, отсутствие даже самых простых оптимизаций, многословный синтаксис (public, private и т.п. перед каждой переменной и полем в классе), GC и прочие прелести невероятно уродуют язык. C++, конечно, в тех задачах, где используется Java, гораздо лучше.

отсутствие даже самых простых оптимизаций, многословный синтаксис (public, private и т.п. перед каждой переменной и полем в классе), GC и прочие прелести

Устраняют 80% совершаемых ошибок при написании кода.

Джава сама по себе большая жирная ошибка

Ну каких ошибок? Конкретный пример можно?

Ошибки целочисленной арифметики, ошибки работы с массивами, ошибки работы с памятью - все эти ваши CVE в большинстве оттуда растут.

Да? И как тогда работает NullPointerException? Если выполнить операцию разыменования на 0, то это UB.

Поясни. Как в твоём представлении связаны NullPointerException и тот факт, что в языках C и C++ поведение кода, который делает разыменование NULL, не определено?

Да даже простейший цикл Java оптимизировать не может.

Что значит «оптимизировать простейший цикл»? Для циклов возможен огромный вагон разных оптимизаций. Многие из которых даже в C нельзя делать, из-за ограниченности языка.

Руками ограничь память. Точно не помню, но ключи назывались вроде -Xmx и -Xms.

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

Ошибки целочисленной арифметики,

Какие-такие ошибки?

ошибки работы с массивами

Какие-такие ошибки? Выход за границу? Ну так это везде ошибка.

ошибки работы с памятью

Какие-такие ошибки? У тех, кто не научился использовать умные указатели?

Поясни. Как в твоём представлении связаны NullPointerException и тот факт, что в языках C и C++ поведение кода, который делает разыменование NULL, не определено?

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

Какие-такие ошибки?

В игре «Цивилизация» был параметр агрессивности лидера - чем больше значение, тем у него стремление вести войну выше. У Махатмы Ганди был самый низкий уровень - 1. А теперь следи за руками: эта переменная была unsigned char и уменьшалась: при открытии религии и открытии демократии. В итоге у Ганди она сначала становилась равной 0, а второй раз - 255. Он быстро заканчивал Манхеттенский проект и всех уничтожал. Это только один пример из игростроя, а так тысячи их - и ты в случае беззнакового целого просто не сможешь понять переполнилась переменная или нет. Поэтому в Java и иных дружественных пользователю ЯП есть только целые со знаком.

Это решается простейшим if

Поэтому в Java и иных дружественных пользователю ЯП есть только целые со знаком.

И как это спасёт их от переполнения?

И как это спасёт их от переполнения?

Решается простейшим if. А вот беззнаковое целочисленное переполнение - не решается.

Целые со знаком не переполняются, по-твоему?

А вот беззнаковое целочисленное переполнение - не решается.

if (aggression_level > 0) написать запрещено каким-то законом природы, или что, я чот не пойму твоего полёта мысли)

Целые со знаком не переполняются, по-твоему?

Переполняются. Но их переполнение можно отловить. Грубо говоря, было 120, мы прибавили что-то и стало -60 - опа.

А с Ганди if (agression_level > 0) не сработает, потому что 0 - тоже допустимое значение.

Но их переполнение можно отловить

Таким же if

А с Ганди if (aggression_level > 0) не сработает, потому что 0 - тоже допустимое значение.

Ты упоролся с утра что ли? Если aggression_level больше нуля, то мы его уменьшаем при принятии демократии и т.д., если не больше - то ничего с ним не делаем. И всё, никакого переполнения.

Если при каком-либо условии aggression_level уменьшается сразу на 2 или на 3, то меняем if соответствующим образом.

Без каких-либо проверок знаковое целое просто уходило бы в минус, и ещё неизвестно что хуже, потому что - что может значить отрицательный уровень агрессии в контексте Цивы? Лидер начинает раздавать свои города другим игрокам? Да скорее всего игра просто упала бы. А так - всего лишь забавный баг, ставший мемом.

уменьшалась: при открытии религии и открытии демократии

Она должна была уменьшаться два раза.

всего лишь забавный баг

А если этот баг означает «немедленный запуск МБР»?

Что значит «должна»? По достижении нуля она как раз не должна уменьшаться, иначе это логическая ошибка.

В игре - ничего страшного.

Ну, а авторы кода забили на «не должна» и вот итог.

авторы кода забили

Вот это и есть причина проблемы. И выкидывание беззнаковых из ЯП тут ничем не поможет.

Чем больше дырявых абстракций, тем больше проблем. Что такое «закон дырявых абстракций» вы наверное знаете.

Сама математика это максимально абстрактная абстракция, так что упс))

А если говорить конкретно об информатике: если выкинуть все абстракции, то тебе придётся писать программы на машинных кодах, и что-то я сомневаюсь, что ты будешь этому рад. Учитывая объёмы и сложность реально полезных программ - как бы после такого шага количество дыр и багов не выросло на два-три порядка.

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

Тут важно чтобы абстракции упрощали, а не усложняли жизнь. Сейчас, часто наоборот. Пишут на интерпретируемой фигне не потому что это имеет смысл (чаще всего не имеет), а потому что только так человек и умеет.

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

Это «городская легенда» - в реальности в игре ничего подобного не было.

Погуглил, действительно. Бодрийяр был бы доволен)