LINUX.ORG.RU
Новости — Java  

Техническая статья Sun «Делаем Java быстрее чем С, используя LRWP»

 , , , , ,


0

0

Начав с технического решения на основе веб-сервера Xitami, имеющего некоторые проблемы с Соларисом (Running a copy in each zone improved performance by more than 100% but still was not the solution to the scalability problem with Xitami), группа инженеров, используя Java и технологию LRWP, добилась производительности на 78% большей, чем у системы на основе Xitami. Xitami назван в статье одним из top10 веб-серверов (one of the top 10 web servers). По отчету Netcraft ( http://survey.netcraft.com/Reports/20... ), на момент написания статьи Xitami имел долю в 0.006% от доли веб-сервера Apache, если считать по количеству сайтов.

>>> Making Java Technology Faster Than C with LRWP

← В Ruby исправлены некоторые уязвимости
Nokia планирует открыть Symbian OS →

  1 2 3 4 5 6 7 8 9 10 11 12 13 14

это наглая провокация флейма

люди пытаются оспорить истину/константу/факты

упорно бьются головой об стену

лучше бы выкинули свою жабу и начали нормальные С/С++/Петон либы писать, без понтов

fMad ★★★
()
Ответ на: комментарий от iZEN

> Уж лучше бы Tomcat сравнили с падучим nginx.

"Падучий" - это из собственного опыта, или так, для красного словца?

kmike ★★
()
Ответ на: комментарий от scaldov

Re^2: Техническая статья Sun "Делаем Java быстрее чем С, используя LRWP"

> недавно на ЛОРе я показывал, что банальный пузырёк на Си выполняется в 2 раза быстрее, чем на яве. (а может и более - у меня шина памяти медленная - ддр2 200/400)

Эти тесты не имеют никакого отношения к реальной работе приложений. Ява работает быстро, С++ программы тормозят и едят больше памяти. Эти тесты не имеют никакого отношения к реальной работе приложений. Ява работает быстро, С++ программы тормо...

Voker57 ★★
()
Ответ на: комментарий от www_linux_org_ru

>>То есть LRWP соотносится с Си.

>тебе не повезло: but LRWP in Java was faster by 23% on a single core system and by 78% on a 4 core system,

Вообще-то судя по статье они задействовали асинхронный фреймворк Grizzly базированный на nio и поэтому (возможно) оно стало масштабироваться лучше. То есть по честному сравнивать они должны были с lighthttpd. Вопрос в том, поддерживает ли lighthttpd протокол LRWP на который у них судя по всему была завязана из система.

Absurd ★★★
()
Ответ на: комментарий от kmike

Из собственного.
nginx прибивался сам-собою под FreeBSD, хотя нагрузки никакой не было. Сегфолт и пиздец тушканчегу.

iZEN ★★★★★
()
Ответ на: комментарий от Absurd

>Вообще-то судя по статье они задействовали асинхронный фреймворк Grizzly базированный на nio и поэтому (возможно) оно стало масштабироваться лучше.

добрый медвед помогает Яве? :)

jodaka ★
()
Ответ на: комментарий от iZEN

>nginx прибивался сам-собою под FreeBSD, хотя нагрузки никакой не было. Сегфолт и пиздец тушканчегу.

Какстрашножить. А когда Вас небыло дома nginx насиловал зазивавшихся прохожих и ел на завтрак детей?

Sidrian
()
Ответ на: комментарий от Absurd

> Вообще-то судя по статье они задействовали асинхронный фреймворк Grizzly базированный на nio и поэтому (возможно) оно стало масштабироваться лучше. То есть по честному сравнивать они должны были с lighthttpd. Вопрос в том, поддерживает ли lighthttpd протокол LRWP на который у них судя по всему была завязана из система.

s/htht/ht/g

AnDoR ★★★★★
()

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

В итоге получается РАБОТАЮЩИЙ бинарник, тяжело поддающийся декомпиляции, и работающий просто офигенно шустро.

Тестировалось мной на смартфонах (BlackBerry, Samsung, Nokia) по сравнению с аналогами скомпилированными на Visual C++.

anonymous
()

Доколе? Доколе я вас спрашиваю?! Доколе Linux будет на убогом и медленном Си? Ведь Си - создан ещё в семидесятых годах! Старье! Убогое старье! Неужели вы не думаете, что за сорок лет не придумали ничего нового, более быстрого? А вы подумайте! Для приближения вендакопеца предлагаю переписать Linux на Java! И тогда система будет обгонять такты процессора!!

CtrlAltBs ☆
()
Ответ на: комментарий от CtrlAltBs

>Доколе? Доколе я вас спрашиваю?! Доколе Linux будет на убогом и медленном Си? Ведь Си - создан ещё в семидесятых годах! Старье! Убогое старье! Неужели вы не думаете, что за сорок лет не придумали ничего нового, более быстрого? А вы подумайте! Для приближения вендакопеца предлагаю переписать Linux на Java! И тогда система будет обгонять такты процессора!!

Согласен частично. Ядро с дровами пусть останется на С+asm, а все что выше должно быть написано на языке уровня Java или C#.

anonymous
()
Ответ на: комментарий от anonymous

>Согласен частично. Ядро с дровами пусть останется на С+asm, а все что выше должно быть написано на языке уровня Java или C#

наглая провокация! Всем ясно, что всё, что выше должно быть на чем нибудь глобальном и надежном... например на php. Ну или хотя-бы на ruby (говорят, там всё поправили и он теперь почти такой же надежный и глобальный, как php)

anonymous
()
Ответ на: комментарий от Byron

> Жаль Томми не дожил :(

да... ява сделала жизнь Томми очень быстрой. Вот, будь он написан на C++ -- до сих пор бы где-то тормозил и ехал..

светлая память

anonymous
()
Ответ на: комментарий от Bioreactor

>JVM - КОМПИЛИРУЮЩАЯ среда. Ключевый слова JIT и HotSpot. Учите матчасть!

Да плюнь ты на них. Дебилы. Один уже как-то спорил что С быстрее JAVA... Пиво все никак не несет. Зажал...

vada ★★★★★
()

Как известно, fortran - самый быстрый язык на свете, даже быстрее ассемблера. Потому что некоторые операции делает напрямую через порты, миную процессор. (C)

atrus ★★★★★
()
Ответ на: комментарий от scaldov

>недавно на ЛОРе я показывал, что банальный пузырёк на Си выполняется в 2 раза быстрее, чем на яве.

Эх ты, пузырек :).

"Теперь я знаю, почему Java так популярна у корпоративщиков. Это ведь просто рай для откатников -- пилителей бюджета: и мега-кластер подавай, вместо пары простеньких сервачков; и на рабочие места несколько компов вместо одного (различным компонентам ПО на стороне клиента разные версии JRE подавай -- с другой они глючат безбожно); и много других хитростей-лазеек для распила бюджета." (с)

Sun-ch ☆
()
Ответ на: комментарий от anonymous

Такой проект есть: JavaOS - http://ru.wikipedia.org/wiki/JavaOS
Кстати, насчёт скорости: если + к оси использовать проц, который исполняет байткод аппаратно, то скорость намного возрастёт, т.к. исчезает прослойка в виде JIT или интерпретатора. Один такой знаю - PicoJAVA, но может есть и более новые разработки

KUser ★
()
Ответ на: комментарий от anonymous

>Согласен частично. Ядро с дровами пусть останется на С+asm, а все что выше должно быть написано на языке уровня Java или C#.

IBM LIC. Все на OS/400

anonymous
()

>Метки: программирование, solaris, c, sun, java, история успеха, глобально и надежно

anonymous
()
Ответ на: комментарий от anonymous

> Согласен частично. Ядро с дровами пусть останется на С+asm, а все что выше должно быть написано на языке уровня Java или C#.

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

CtrlAltBs ☆
()
Ответ на: комментарий от scaldov

>недавно на ЛОРе я показывал, что банальный пузырёк на Си выполняется в 2 раза быстрее

Покажи еще раз. Не нашел в твоих постах.

vada ★★★★★
()
Ответ на: комментарий от KUser

>Кстати, насчёт скорости: если + к оси использовать проц, который исполняет байткод аппаратно, то скорость намного возрастёт, т.к. исчезает прослойка в виде JIT или интерпретатора. Один такой знаю - PicoJAVA, но может есть и более новые разработки

Такие процессоры ненужны. Сишникам не останется возможности придумывать костыли в виде JIT и JVM и каких-то там сраных операционок с ручным управлением закатом солнц.

iZEN ★★★★★
()
Ответ на: комментарий от anonymous

>Вот, будь он написан на C++ -- до сих пор бы где-то тормозил и ехал..

Это вряд ли. Меморилики недалеко бы его отпустили.

iZEN ★★★★★
()

Боже, ну и статья... `Делаем запорожец быстрее феррари с помощью домкрата' :))

Для начала пусть нормальный garbage collection в своей яве осилят.

anonymous
()
Ответ на: комментарий от anonymous

>Для начала пусть нормальный garbage collection в своей яве осилят.

Нормальный — это какой? Их там уже несколько, под разные задачи.

WFrag ★★★★
()
Ответ на: комментарий от WFrag

> Нормальный -- это какой? Их там уже несколько, под разные задачи.

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

anonymous
()
Ответ на: комментарий от KUser

>Кстати, насчёт скорости: если + к оси использовать проц, который исполняет байткод аппаратно, то скорость намного возрастёт, т.к. исчезает прослойка в виде JIT или интерпретатора. Один такой знаю - PicoJAVA, но может есть и более новые разработки

Ерунда. JIT — это не прослойка и влияет он в основном на время старта/"разогрева", для долгоработающего сервера это не критично.

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

Что могло бы сильно помочь — это теггированная память и forwarding pointers.

WFrag ★★★★
()
Ответ на: комментарий от CtrlAltBs

>Из недавнего. Тут человек пытался доказать превосходство Java и обкакался-с. Хотите так же? Продолжайте.

Там смешные замеры. У Java скорость выполнения сильно зависит от параметров и "прогретости" (см. -XX:CompileThreshold).

WFrag ★★★★
()
Ответ на: комментарий от WFrag

> Там смешные замеры. У Java скорость выполнения сильно зависит от параметров и "прогретости" (см. -XX:CompileThreshold).

Угу, ещё с астрологами посоветоваться, когда там звезды на небе сойдутся. Вот тогда и замерять!

CtrlAltBs ☆
()
Ответ на: комментарий от WFrag

>И, насколько я знаю, непосредственно выполнять байт-код — медленно,

В PicoJava применили оригинальное решение: верх стека находится внутри проца, и потому скорость доступа к нему как к регистрам, байткод транслируется в RISC- команды, причём иногда со склейкой 2-3 команды байт-кода в 1 RISC, кроме того код для стекового проца компактнее, так что извлекать из памяти его можно быстрее.
Вот тут есть описание http://www.osp.ru/os/1999/01/179635/_p1.html

KUser ★
()
Ответ на: комментарий от CtrlAltBs 

>Угу, ещё с астрологами посоветоваться, когда там звезды на небе сойдутся. Вот тогда и замерять!

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

wfrag@fragentoo ~/1 $ cat test.c 
#include <stdio.h>

int main(void) {
    long c = clock();
    int l = 0, i, j;
    for( j = 0; j < 10; ++j ) {
        for( i = 0; i < 1000000000; ++i ) {
            l += i;
        }
    }
    long end = clock(); 
    printf( "l = %d\n", l );
    printf("%ld\n", end - c);
    return 0;
}

wfrag@fragentoo ~/1 $ cat Test.java 
import java.lang.management.ManagementFactory;
import java.lang.management.ThreadMXBean;


public class Test {
    public static void main(String[] args) {
        test();
        test();
    }

    public static void test() {
        ThreadMXBean mx = ManagementFactory.getThreadMXBean();
        long c = mx.getCurrentThreadCpuTime();
        int l = 0, i, j;
        for( j = 0; j < 10; ++j ) {
            for( i = 0; i < 1000000000; ++i ) {
                l += i;
            }
        }
        long end = mx.getCurrentThreadCpuTime(); 
        System.err.println( "l = " + l);
        System.err.println((end - c) / 1000);
    }
}

wfrag@fragentoo ~/1 $ gcc -O3 test.c
wfrag@fragentoo ~/1 $ javac Test.java 
wfrag@fragentoo ~/1 $ ./a.out 
l = 451808768
10530000
wfrag@fragentoo ~/1 $ java -cp . -XX:CompileThreshold=10 -XX:+AggressiveOpts -server  Test
l = 451808768
15180000
l = 451808768
5640000


Речь даже не об том, что у меня Java код быстрее выполнился (на
второй проход), я может и компилять-то не умею :) А речь о том, что
второй проход в 2.7 раз быстрее первого, потому что сработал JIT.

И, например, на сервере это более чем приемлемый вариант, ибо там
время прогрева и старта не особо имеет значение.

WFrag ★★★★
()
Ответ на: комментарий от anonymous

>Согласен частично. Ядро с дровами пусть останется на С+asm, а все что выше должно быть написано на языке уровня Java или C#.

Вот поскорее бы МС прислушались к жабакодерам и переписали все на точкаНЕТ, выкинув ВинАпи...

Sidrian
()
Ответ на: комментарий от scaldov

>недавно на ЛОРе я показывал, что банальный пузырёк на Си выполняется в 2 раза быстрее, чем на яве. (а может и более - у меня шина памяти медленная - ддр2 200/400) Недавно на ЛОРе я показал, что scaldov в два раза тупее пациента психушки.

опять дураков понабилось.

anonymous
()
Ответ на: комментарий от scaldov

>> Дык онаж вроде и так быстрее C и Ассемблера вместе взятых?
> совсем дурак?

совсем шуток не понимаем?

lester ★★★★
()

Мммдаа.... Господа, вы напоминаете дрочеров, которые покругу наяривают друг другу. Из вас хоть один программист есть? Или все нубы как в джаве, так и в Си? Я так посмотрю, грамотные специалисты обходят подобные топики стороной - и правильно делают! Учите мат. часть! Да и научиться программировать хотя бы Hello World на парочке-тройке языков не помешало бы.

anonymous
()
Ответ на: комментарий от anonymous

Ты до сих пор не знаешь как пишется Линукс?

KUser ★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
  1 2 3 4 5 6 7 8 9 10 11 12 13 14
← В Ruby исправлены некоторые уязвимости
Java
Nokia планирует открыть Symbian OS →