OSDev

Почти с самого начала треда гложет мысль, да высказать некогда было: пофиг на языки, они не так уж много значат, а вот чего интересно в сравнении в первую очередь: какое время измеряем? Только время выполнения (без учёта времени компиляции) или полное время компиляции+выполнения? При использовании JIT (которые зачастую используют когда хочется быстрый старт + набор статистики профилирования + JIT генерация машинного кода для кусков программы, определённых как горячие, в то время как для вычислений на быстрый старт пофиг, зато важно чтобы на этапе компиляции было вылизано всё что можно) отделить мясо от мух не так-то просто. Да и смешивать в кучу Java и JVM нехорошо (а создалось впечатление что тут это не различают).

А если хочется языки сравнивать - это надо, наверное, брать gcj и gcc (когда компилятор один и различаются только фронтенды разбора и, быть может, библиотеки времени выполнения).

В той системе сравнивается процессорное время работы программы. То время, которое процессор тратил на исполнение именно запущенной программы.

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

Java это набор технологий и стандартов. Как единое целое этот набор можно сравнивать с таким же альтернативным набором. Под JVM вы видимо имели в виду компилятор, который есть единственный компонент, важный для скорости перемножения матриц. Поэтому при разборе перемножения матриц имеем по сути сравнение двух компиляторов - из среды обитания Java и из альтернативной среды. Но с точки зрения единого целого набор технологий для ускорения расчётов С позволяет использовать ассемблерные вставки, а в Java нужно отдельно писать нативные методы. В этом я вижу временное небольшое отставание, ну да его скоро ликвидируют.

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

Это не размышления, это доклад об опытных данных. Почувствуйте разницу, как говорится.

64 битная Java под рукой отсутствует (ибо нет ОС на 64 бита), поэтому здесь я могу только теоретически сказать - разница в производительности Java и С будет минимальной.

И даже выше было показано, как это сделать на 32-bit Java.

Именно о таком варианте я и говорил выше в докладе об экспериментальных данных.

Разные-то разные, но разница в весе и росте не должна сказываться на объективности оценок при сравнении двух наборов технологий. Но вот у некоторых почему-то сказывается.

Это неправильная гипотеза. Не угадали вы мои мысли

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

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

Вы пришли на этот форум и заявили, что в ВАШЕЙ области вы всё познали и более вам ни кто ничего не докажет. В ответ на такое смелое заявление я вам привёл пример Java, на который вы отреагировали весьма болезненно, начав разговор о том, что область-то ВАША и что все остальные в ней просто бараны и не должны вам чего-то советовать (это образное выражение вашей позиции и не имеет дословного подтверждения, естественно).

И вот в ВАШЕЙ области я вам указал, что суть вашего сравнения сводится к сравнению компиляции одного простейшего цикла. Помимо указания были приведены опытные данные. Но вы просто заявляете - не выйдет.

Можно предположить, что вы так "неформально" понимаете выражение "решить задачу". Но опять же я вам напоминаю, что решением вашей задачи будет достижение скорости перемножения матриц порядка 5000 за менее 100 секунд на 2.4 ГГц процессоре. А для достижения такой скорости нужно оптимизировать ОДИН ЕДИНСТВЕННЫЙ цикл. Конечно, в ВАШЕЙ области возможно считается, что простые решения - они для посторонних (не из вашего района ), но тем не менее, решение задачи именно простое и заключается именно в одном единственном цикле. То есть на лицо ваше застревание в локальном экстремуме, выход из которого для вас закрыт нежеланием посмотреть правде в глаза - задача решается через ОДИН цикл (точнее - его оптимизацию).

То есть весьма полезно иногда заглянуть в чужую область и обнаружить там застоявшееся болото Может всё же пробужу желание попытаться выбраться из застоя.

Выложил сравнение производительности Java и альтернативных подходов. Вот ссылка. Без ассемблера и интринсиков С компиляторы в идеале могут быть процентов на 30-40 быстрее. Но в реальности, подозреваю, силёнок им не хватает и выдают производительность где-то на уровне Java.

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

Вау, вот это я понимаю - верх удобства. Просто идеал. Всего-то 20 строк кода для умножения двух чисел через mul. А какая читаемость! Встроенному ассемблеру у сишных компиляторов такая и не снилась.
А по делу - java заявляется в первую очередь как кроссплатформенный язык со сборкой мусора. При использовании встроенного ассемблера полностью исчезает кроссплатформенность, и ставится под вопрос полезность и адекватность сборки мусора. В итоге остается только "язык". С очень, ОЧЕНЬ сомнительным удобством и полезностью этого ассемблера. Например, учитывая, что в Java почти всё есть объект, как на этом встроенном ассемблере удобно обращаться к полям объекта? В статье не нашел. Полагаю, что через вызовы каких-то хитрых функций, по аналогии с общением JVM и нативного кода во внешних библиотеках. А такое резку срубает пользу от ассемблера при, например, работе с массивами.
И, кстати, из этой же статейки:

По этим результатам видно, что "ассемблерная" реализация (т.е. через эти самые дико кривые асм-вставки) с SSE работает в 3-5 раз быстрее обычной джавы.

Бред сивой кобылы, не имеющий ни одного факта под собой. А вернее, откровенная ложь.
Нормальные компиляторы Си гоняют SSE в хвост и в гриву везде, где только могут.
И даже если посчитать это заявление правдой, все равно получается, что чистая java на 30-40% медленней чистого Си, т.к. GPR-Only вариант (на уровне которого по заявлению автора статьи работает Си) в данном тесте тоже был написан на ассемблере, только без SSE, и все равно оказался сильно шустрее жавы.

Вы видели программу Hello World на ассемблере ?

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

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

О да, главное указать, что Java всё равно хуже, ведь сам автор признаёт, что она не идеальна

Вы, конечно же готовы предоставить результаты тестирования С-компиляторов на предмет опровержения бреда сивой кобылы ? Или просто треплетесь без минимального обоснования фактами ?

Так вот и покажите нам чистый С, который хотя бы на 30-40% быстрее чистой Java. А то заявления делать все умеют, а вот доказать что-то - мало способных.

Тов. эмбрион, Вы всё ещё не понимаете в чём смысл данной темы. Я сказал, что ни один жава программист не решит на жаве задачи, которые я считаю простыми. Совершенно не интересует сравнение компиляторов жавы с другими языками, и так ясно, то она проигрывает без всяких сравнений. Интересует сравнение полного комплекса: программист + язык. Не важно, какой программист и не важно какой язык в отдельности друг от друга. Но важно, что по моим наблюдениям любители (ярые приверженцы) жавы совершенно не способны решать простые задачи (и сложные тем более), потому что есть чёткая корреляция между способностями решать задачи и способностями мыслить. Неспособность мыслить широко выражается разными способами: от яростной любви к жаве, до неумения решать простые задачи. Вот именно это никто до сих пор мне не опроверг в моей практике.


Вот это одна из ошибок. Нам как раз важно, чтобы задачу можно было решать. Представьте, вам говорят: постройте проект здания. Вы отвечаете: ну, пожалуйста, это займет 2 миллиона лет, нам же не важна эффективность. А на самом деле важна. И поверьте, все Ваши рассуждения о том, что кто-то там на 30-40 процентов медленнее - это лишь фантазии, основанные на одном единственном примере бездарно реализованного метода. На другом примере будет другое расхождение и человек, который претендует на умение сравнивать компиляторы, должен это знать.


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

Короче, эмбрион, результатов, полученных на правильном решении задачи пока не видно. Правильным решением я считаю то, которое проходит неизвестные вам тесты на сайте указанного мной проекта. Я, честно говоря, устал доказывать что-либо фанатикам, поэтому последнее время просто даю задачи и спокойно забываю про человека, так как я знаю заранее, что задачи решены не будут. Очень удобно : )

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

Да, замок создаёт иллюзию неприступности. Но вот летающий над вами на вертолётах народ об этом, почему-то, не подозревает ...

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