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

Kolibri os

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

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

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

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

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

Вообще от дистрибутива зависит, скорее всего. В KDE Neon Unstable, куда все наработки с шестой плазмой сливаются, там 6.6. У OpenSUSE Tumbleweed тоже 6.6. Наверное в окаменелостях вроде Дебиана будет 6.4.2 итп.

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

Паскаль и Си примерно одинаковые по скорости. А вот Си и Python будут отличаться очень сильно.

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

Потому что она интерпретируемая и с 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.

У меня десктопу 12 лет

У меня примерно столько же. Как бы я не наблюдаю критических тормозов, подтормаживают в основном свистоперделки по типу вывода всех окон при наведении на угол. При этом аналогичные фичи в компизе не тормозят. То есть тормозит по сути только kwin, к остальным частям KDE претензий нет.

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

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

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

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

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

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

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

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

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

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

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

что в Java нет UB

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

KDE уже идеален и является общественно признанным лучшим ДЕ на линукс, что ещё можно улучшить? Возможно, это будет последний гвоздь в гроб наркогнома и прочих васянских поделок, по ошибке называемых ДЕ.

Надеюсь в Kubuntu 24.04 будет?

полноценный релиз Frameworks 6.0, Gear 24.02 и Plasma 6.0

Интересно сколько будет оно жрать

Да Гном сам справляется, заколачивает свой гроб изнутри.

KDE5 реально хорош, тут главное, чтобы ничего не испортили.

KDE5 реально хорош

Не соглашусь) Есть над чем работать, недостатков хватает.

Что ты несёшь? 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 соответствующим образом.

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

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

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

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

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

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

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