C vs. JVM's benchmark

>Или ты один из тех которые признают скорее что сотни людей психи чем прозреют наконец что программы есть - просто _они_ они них не знают?

Не будете ли Вы так добры привести список(или просто количество) десктопных приложения в репозитариях Зюзи написаных на С/С++?

>Десятком програм из этого списка япользовался. Некоторые еще посмотрю - пока не полез соствалять список - не знал о существовании.

Тоесть даже сами жабакодеры с многолетним стажем юзали на десктопе всего 10 приложения написаных на Жаве и не подозревают о существовании остальных? Что и требовалось доказать.

>Интересно - это признак идиотии когда ему показывают список из 100 порграм репоззитария а он утверждает что они не сущуствуют глядя прямо на него?

Нет, признак идиотии, это когда человек не может посчитать, что 100 программ в репозатарии среднестатистического дистрибутива это обычно как раз около одного процента. Жаба Головного Моска мешает считать?

>> И какая в этом проблема? Всегда будут разные уровни абстракции.

> А где они разные?

Ну ни фига себе.

> JVM по факту экзекутит код

JVM его только транслирует, исполняет - процессор.

> занимается управлению памятью

Ага, ведет кэш, свопинг, обрабатывает страничные отказы.

> процессами

Нитями.

> контролирует синхронизацию.

Опираясь на реализованные в ядре примитивы.

Ну и чисто для завершенности - мелочи типа ФС, протоколов и драйверов.

> jvm - это ядро внутри ядра дя еще и в юзерспейсе.

Не дублирует JVM ядра. Могла бы, наверное, но не делает.

>>Поправь меня, если я ошибаюсь, но это целиком вина рантайма JVM, причем обычный AOT ее решает :D

>Нет. Аот просто статически все слинковывает и все. В JVM есть иерархическая модель класслоадеров со своей собственной изоляцией которую никакие аоты не учитывают.

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

> А пока отно работает отдельно - что вы хотите? При таких условиях производительность в 2 раза - это вообще крутизна.

Если речь о замерах из сабжа, то они не из-за дублирования ОС, а из-за неэффективности JIT.

Хватит выкручиваться. Ты говорил "Ну не пишут десктопные апликухе не жабе. И не будут." На самом деле они есть и пишутся.

Ты слил.

>Хватит выкручиваться. Ты говорил "Ну не пишут десктопные апликухе не жабе. И не будут." На самом деле они есть и пишутся.

Понятно. Тоже невменяемый...

>Не будете ли Вы так добры привести список(или просто количество) десктопных приложения в репозитариях Зюзи написаных на С/С++?

Не будешь ли ты так любезе привести список програм написаных на Qt/GTK под венду. Потому сравнить его со списком програм написанных под венду без этих замечательнейших продуктав и сделать выводы о ненужнсти оных.

>Тоесть даже сами жабакодеры с многолетним стажем юзали на десктопе всего 10 приложения написаных на Жаве

Ты посчитай сколько всего програм ты пользуешь в повседневной жизни и сравни это число с десятью. А потом сделай выводы если есть чем.

Все - надоело разговаривать с идиотом.

>>Я легко себе представляю ситуацию, когда это абсолютно критично.

>Но относится ли это к к десктопам и сереверам не занимающимся HPC? Вот в чем вопрос.

К встроенному железу, скорее.

>>Managed-код - это программная эмуляция аппаратных механизмов защиты.

>ТАм где их сейчас не хватает. Да. Плюс некоторые свойства - например поддержка compacting GC железом.

Только вот использование для этого в ядре ОС JVM или подобного выглядит афигенным overkill.

>Не будешь ли ты так любезе привести список програм написаных на Qt/GTK под венду. Потому сравнить его со списком програм написанных под венду без этих замечательнейших продуктав и сделать выводы о ненужнсти оных.

Не использую венду. Кого волнует состав кактуса?

>Ты посчитай сколько всего програм ты пользуешь в повседневной жизни и сравни это число с десятью. А потом сделай выводы если есть чем.

Могу тебе по секрету сказать, что за годы использования ПК я юзал немного больше 10 приложений. На жаве всего 2 - Азуреус от которого я отказался в пользу легкого Трансмишена и Еклипс, потому что ВиндРивер сделали Воркбенч на его основе и иногда все таки приходится юзать это чудо место Эмакса.

>Все - надоело разговаривать с идиотом.

Что такое пастушок, обидели любимый фетиш?

>> процессами

>Нитями.

И процессами тоже, JVM например в линуксе использует LWP.

>> контролирует синхронизацию.

>Опираясь на реализованные в ядре примитивы.

Опять в лужу. В Яве своя модель concurrency, которая не зависит от ядра. Ознакомся хотя-бы с понятием монитора в Яве.

Кстати, безотносительно к теме о том, что, где и как Java sucks... кто-нибудь пожет кинуть ссылку на последние анонсы IBM Research о скростных микросхемах? А то гугель выдает кучу нерелевантного мусора.

>>Хватит выкручиваться. Ты говорил "Ну не пишут десктопные апликухе не жабе. И не будут." На самом деле они есть и пишутся.

>Понятно. Тоже невменяемый...

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

>>ТАм где их сейчас не хватает. Да. Плюс некоторые свойства - например поддержка compacting GC железом.
>Только вот использование для этого в ядре ОС JVM или подобного выглядит афигенным overkill.

С Си на Java переписывают драйверы для Sun Solaris

Программисты Хироши Ямаучи и Марио Волчко переписали драйвер уровня ядра, прежде написанный на языке Си, на языке Java.

Экспериментальная виртуальная машина (JVM) Squawk работает на уровне ядра операционной системы Sun Solaris. Она позволяет исполнять независимый от процессора байткод, реализующий функции драйверов различных устройств, которые прежде были представлены в нативном двоичном коде процессора.

Апрель, 2006

http://research.sun.com/techrep/2006/abstract-156.html

>JVM его только транслирует, исполняет - процессор.

Чем это отличается с точки зрения уровня от, например загрузки PE файла в венде?

>Ага, ведет кэш, свопинг, обрабатывает страничные отказы.

Управляет указателями, двигает память, выделяет и освобождает ее - это разве не где-то рядом?

>Нитями.

Тоже рядом.

>Опираясь на реализованные в ядре примитивы.

Конечно. Но тем не менее задача эта - это расширять возможности ядра. Это явно не прикладной уровень - это уровень ядерный.

>Не дублирует JVM ядра. Могла бы, наверное, но не делает.

Но занимается работой которой ей не хватает от ядра:)

>AOT переводит класс из байт-кода в машкод.

Само приложение становиться "статически-слинкованым" и уже не учитывает возможности рантайма. Как пример - запуск нескольких приложений в одном рантайме.

>Если речь о замерах из сабжа, то они не из-за дублирования ОС, а из-за неэффективности JIT.

В чем именно?

>К встроенному железу, скорее.

ДА. А к обычным серверам и десктопам - врядли.

>Только вот использование для этого в ядре ОС JVM или подобного выглядит афигенным overkill.

Достаточно научить ядро этому всему:)

>Понятно, просто человек не умеет отвечать за свои слова.

Понятно, что ЖГМ не дает Вам объективно оценивать свой фетиш. Вот я же не предлагаю Вам сайтеги-хоумпаги на Ц лобать? А Вы сейчас ведете себя именно так.

>>> процессами

>>Нитями.

>И процессами тоже, JVM например в линуксе использует LWP.

Ну, поиграй терминами, поиграй. Потом подумай, есть ли разница между "процессом" и LWP.

>> Опираясь на реализованные в ядре примитивы.

> Опять в лужу. В Яве своя модель concurrency, которая не зависит от ядра.

Ой, правда? И футексы она не использует?

> Ознакомся хотя-бы с понятием монитора в Яве.

Да уж лет 10 назад. Не говоря о том, что мониторы отнюдь не Ява изобрела.

>Не использую венду. Кого волнует состав кактуса?

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

>Что такое пастушок, обидели любимый фетиш?

Нет - просто надоело говорить с идиотом.

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

>Пастушок, ты же теперь все таки в большом городе живешь, так что веди себя прилично.

С идиотами? Увольте.

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

>> JVM его только транслирует, исполняет - процессор.

> Чем это отличается с точки зрения уровня от, например загрузки PE файла в венде?

Тем, что венда не транслирует команды бинаря с родным кодом, а просто передает туда управление.

>> Ага, ведет кэш, свопинг, обрабатывает страничные отказы.

> Управляет указателями, двигает память, выделяет и освобождает ее - это разве не где-то рядом?

Это идеологически близко, но совсем не то.

>>Опираясь на реализованные в ядре примитивы.

>Конечно. Но тем не менее задача эта - это расширять возможности ядра.

Есть разница между расширением и дублированием.

> Это явно не прикладной уровень - это уровень ядерный.

Ну, это мы занесем в протокол разногласий %)

>> Если речь о замерах из сабжа, то они не из-за дублирования ОС, а из-за неэффективности JIT.

> В чем именно?

Вероятно, из-за ограничений по времени JIT недостаточно хорошо оптимизирует (сравни результаты JET и Sun).

2Sidrian

Не кури это больше.

>> Только вот использование для этого в ядре ОС JVM или подобного выглядит афигенным overkill.

> Достаточно научить ядро этому всему:)

Зачем? Ядро - программа относительно небольшая, развитие железа сделает практически применимыми микроядерные и похожие техники, так что будем иметь математически верифицированное микроядро, и disposable процессы-спутники :)

String result = a.concat(b);

Отсыпать?

> проверь на своем компиляторе и отпиши результат ;)

3,3,3 :))) но при этом gcc накидал кучу варнингов - так что зевнуть такое место просто невозможно

>Тем, что венда не транслирует команды бинаря с родным кодом, а просто передает туда управление.

Это технический момент. Она распаковывает файл раскладывает его по памяти и отдает управление. Считай что JIT - это тоже распаковка - только умная, адаптивная. Когда-то давно экзешники в зип зажимали с рспаковщиком в заголовке - принципиально то какая разница?

>Это идеологически близко, но совсем не то.

Но очень рядом:)

>Есть разница между расширением и дублированием.

Некоторые вещи дублируются - напримел выделение и освобождение памяти. Вследствии невозможности смержиться с ядерными механизмами - приходится хавать все пачкой и заниматься этим самому.

>Вероятно, из-за ограничений по времени JIT недостаточно хорошо оптимизирует.

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

>ачем? Ядро - программа относительно небольшая, развитие железа сделает практически применимыми микроядерные и похожие техники, так что будем иметь математически верифицированное микроядро, и disposable процессы-спутники :)

А зачем защищенный режим?:)

> Достаточно научить ядро этому всему:)

флаг тебе в руки, исправляй ядро. я так уже давно делаю, добавляю свой функционал - покруче всякой JVM получаются вещи)))

>А зачем защищенный режим?:)

x86 не нужен.

> Когда-то давно экзешники в зип зажимали с рспаковщиком в заголовке - принципиально то какая разница?

Принципиально это всё машины Тьюринга. Но вот unzip на пару порядков проще.

>>Есть разница между расширением и дублированием.

> Некоторые вещи дублируются - напримел выделение и освобождение памяти

Ну блин, тогда и malloc отнесем к дублированию.

>>Вероятно, из-за ограничений по времени JIT недостаточно хорошо оптимизирует.

>Да - но опять же когда сам рантайм станет частью среды исполнения - как минимм его можно компилить и кешировать.

Правильно! А если это делать до запуска, то рантайму даже не нужно становиться частью чего-либо ;)

>> будем иметь математически верифицированное микроядро, и disposable процессы-спутники :)

> А зачем защищенный режим?:)

Потому что процессы-спутники верифицировать не будем, считая их слишком сложными (так же, как не будем верифицировать JVM). Пусть падают :)

Вот понаписали! Как в теме про php. Чем плох такой код на C++:

#include <iostream> #include <string> using namespace std; int main(int argc, char**argv) { if (argc > 2) { string test(argv[1]); test.append(argv[2]); cout << test << endl; } else cout << "[str1] [str2]" << endl; return 0; }

Кстати, про яву и разные архитектуры, код без проблем скомпилен gcc3.3 прямо из под Windows Mobile. JVM, тоже есть. Но на 27 метрах она стартует не особо шустро :(

>Ограничена ява. Какие задачи, выполнение которых возможно осуществить на яве невозможно выполнить на Си?

>>Все задачи можно выполнить на ассемблере. Вперед и с песней.

Разве то, что задачи можно выполнить на ассемблере отменяет ограниченность явы? Да, и ассемблер и СИ - универсальные инструменты, способные решать ЛЮБЫЕ задачи (пусть и путем больших временных затрат) как конечных продуктов, так и задачи создания инструментов для получения этих продуктов (i.e. IDE, языки программирования).

>>Enterprise Class Portals, IDE. Валяй - ищи.

IDE вполне достаточно написано на C/C++, относительно порталов - они писались и ДО появления явы, и про гугл здесь тоже уже говорили.

>Во первых пишут во вторых переписывать работающий софт ради того чтобы он был написан на любимом языке могут только красноглазые маньяки.

>ТЫ пропустил интересный топик. Перемалывае его мне облом. В репах сусе десктопных жабскиж програм - сотня. Почему не переписівают все 5ть программ которыми ты пользуешься подумай сам.

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

>>Почему не переписівают все 5ть программ которыми ты пользуешься подумай сам.

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

>> >Ограничена ява. Какие задачи, выполнение которых возможно осуществить на яве невозможно выполнить на Си?

>>Мега-Веб-сервер от Сана, работает в 10 раз быстрее, чем второй апач и Tomcat.

Ой, блин, а хостеры то не знают... лепять везде апач да ngnix, им ведь не дорого процессорное время (да че говорить, вообще ресурсы) и на одном сервере они размещают по одному сайту, а поставили бы сервер от сана - могли бы два разместить, при этом на виртуальном сервере, денег бы больше заработали... Срочно им напишите!

>пожалуйста, хотя бы парочку примеров, где используется ОС написанная на Java.

Может Androind ?

про Java приложения можно сказать следующее:
т.к. Java App требует своего окружения в глобальных масштабах Java App не так популярны так же как и апплеты, потому что это заморачивает пользователей на установку доп. софта (JRE) в глобальном мире Windows с этим вообще проблема (она есть и в Linux) в отличии от дотНета. но интерпрайс сектор, где действуют разные полиси могут себе это позволить и позволяют :) потому что это читай глобально и надежно.
Тоже самое можно сказать и о JEE приложениях. сервера тяжело саппортить потому что сложная функциональность, конфигурация, много функций, технологий. проще поставить апач с его производительностью, прикрутиь пхп странички с его производительностью и не парится. что не скажешь о больших корпоративных системах, где важно не только время отклика, расчет, многопоточность, транзакционность и тд но и сроки на реализацию всего этого.
поэтому большинство из школьников не видит Java как таковой. а она есть и чувствует себя не плохо.

>> Apache Tomcat. Написан на Java. :P >незачот! во-первых - это apache модуль, написанный на C

никаму не говори только это еще раз ага??

Вот не понимаю как можно так сравнивать :((((

Можно токо сравнить программу написаную на Си и JVM ( она тоже программа
и тоже написана на Си ) Почему ни кому в голову не приходит сравнивать Монитор и мышь ?

CPU <- Code <- C
CPU <- Code(JVM) <- Java(статическая типизация)
CPU <- Code(JVM) <- Groovy-interp(статика) <- Groovy прога ( динамика )

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

1. Программа на Си VS программы на С++
2. Программа на Java VS программа на Mono ( статика )
3. Groovy VS PHP VS Ruby VS Python etc ( динамика )

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

Надеюсь я понятно излагаю ;)

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

вот тесты и показывают, что в конкретных вещах jvm лишь незначительно "несовершеннее"=>если вы готовы пожертвовать 10-30% производитеьности ради более быстрой разработки(в процентах не назову, увы, но поболее 10-30% имхо) - то java для вас предпочтительнее си

>Например, у меня работает ферма Tomcat'ов с nginx'ом перед ними для load ballancing'а.

Если Tomcat умеет кластеризоваться, то load ballancing на nginx'е, по идее, не нужен. Или я шибаюсь?
http://tomcat.apache.org/tomcat-6.0-doc/cluster-howto.html

Согласен но это только конкретные вещи. Если взять к примеру
нормальные десктопные приложения то нужно примении SWT ( читай как Сишные ) либы !

Может в этом случае еще удешевить процесс и написать на PyGTK ?
Это будет типа связка - Си и Питон.

Или взять тот же ВЕБ ? Нжуно ли тама это J2EE ? Может дешевле и быстрее пхп обойтись ? Или как гугл - сделали апп-енжине на Питоне ...

>Опять в лужу. В Яве своя модель concurrency, которая не зависит от ядра. Ознакомся хотя-бы с понятием монитора в Яве.

Прямой аналог POSIX-ного condition variable, насколько я помню (могу врать :) ). Судя по исходникам, реализация Sun JVM под Linux именно их и использует (вкупе с pthread-ами).

>Или взять тот же ВЕБ ? Нжуно ли тама это J2EE ? Может дешевле и быстрее пхп обойтись ? Или как гугл - сделали апп-енжине на Питоне ...

Для Web дешевле и быстрее поставить Tomcat без всяких Apache-серверов и заняться написанием JSP/Servlets/использовать готовый фреймворк JSF.

Так нет же, PHP-шники лучше сделают RAID-0 из 4 дисков, чем докупят ещё одну плашку памяти 1GB, чтобы интерпретатор PHP не тормозил.

>Или как гугл - сделали апп-енжине на Питоне ...

Не на Питоне, а для Питона. Реализация Big Tables у них явно не на Питоне сделана :)

>Прямой аналог POSIX-ного condition variable, насколько я помню (могу врать :) ). Судя по исходникам, реализация Sun JVM под Linux именно их и использует (вкупе с pthread-ами).

Вернее так. Аналог захвата/освобождения монитора — это pthread_mutex, мутекс, а wait/notify/notifyAll — это pthread_cond_wait/pthread_cond_signal/pthread_cond_broadcast. Семантика прям такая же — при ожидании муекс освобождается.

И даже те же spurious wakeups возможны там и там :)

зачем нужен php, когда есть тот же grails?

> Не на Питоне, а для Питона.
ну хз по крайне мере то что они дают скачивать для отладки и написания
все это на питоне

> Реализация Big Tables у них явно не на Питоне сделана :)
Мне болше кажеться что это Си хотя хз ...

> зачем нужен php, когда есть тот же grails?

Ну это не совем верно лучше произнести так :
зачем нужен grails если уже давно есть php

Опять же все зависит от задач. Вон wordpress на php
и вроде не напрягает народ .... могут начать орать про масштабируемость
но в случае с php оно вроде достигаеться на более низком уровне
load_balancing ну и подобное.

Вот к примеру лор - тут не сервлеты а jsp и скорее всего все написано
также как подобная страница выглядела бы на php но с жавовским синтаксисом ;)

> единственые причины по которым 99% десктопного софта пишут не на Жаве - это тупость девелоперов

Загляните на sourceforge, посмотрите статистику, большинство проектов на Java. Где ещё смотреть десктопный софт?

Вообщето jsp компилируются в сервлеты. И писать в стиле php(так можно) считается большинством программистов на java плохим решением.

>Загляните на sourceforge, посмотрите статистику, большинство проектов на Java. Где ещё смотреть десктопный софт?

Вы удивитесь: десктопный софт нужно искать на десктопе. На моем десктопе, десктопе друзей, даже на десктопах вендузятнегов на работе я жаба-софта не наблюдаю особо. А что Вы используете на десктопе написаное на Жаве?

Мой десктоп слегка переплетается с работой, поэтому скажу те программы, которыми я чаще всего пользуюсь. Eclipse [Java], Firefox, maven [Java], Squirrel SQL Client [Java], Azureus [Java], Evince, gnome-terminal.