Смотрел на Java код. ...много думал.
От: c-smile Канада http://terrainformatica.com
Дата: 28.10.05 21:52
Оценка: 126 (13) +10 -5 :))) :)
Вот такой вот показательный пример,

Фрагмент (очень неполный) читает нечто по протоколу superset of http

Комментарии в тексте мои.
Внимание! я не критикую автора. Я просто хочу обратить внимание
на то как safe код фактически рушит систему — код работал на клиенте
и возникла потребность перенсти его на сервер. Сервер не сказать
чтобы умер — просто перестал "серверить".



class ReaderThread extends Thread
    {
    InputStream input_stream = null;
    Socket socket = null;
    ByteBuffer readBuffer = new ByteBuffer();
        ByteBuffer line = new ByteBuffer();
        ....

    public void run ()
    {
            ....
            // Читаем посимвольно - набиваем буфер.
            // сюда мы попадаем не для каждого IP адреса
            while( (ch = input_stream.read()) != -1 )
            {
              .... 
              if(конец строки и еще кое что) 
              ....
                // Пеночка №1: чтобы сделать нечто полезное с текстовыми (ASCII)
                // данными их надо в строку widechar загнать. 
                // Не барское это дело с bytes работать.
                // Реаллокация буфера №1 - кол-во байт +2N. 
                   String header_line =  new String( line.get() );

                // Пеночка №2: делаем еще одну строку потому как нам надо 
                // регистронезависимый парсинг делать. 
                // Реаллокация буфера №2 - кол-во байт +2N+2N. 
            header_line = header_line.toUpperCase().substring( 0, len - 2 );

                // Теперь собсвенно вызываем startsWith - для чего и делалась вся
                // бодяга выше.
        if( header_line.startsWith( HttpHeader.HTTP_CONTENT_LENGTH ) )
        {
                    // Щаз будем парсить.
                    // Аллокация объекта - сколько ест - то нам не ведомо. 
            StringTokenizer v = new StringTokenizer(header_line, ": ");

                    // Теперича значить толкаем на стек try frame
                    // потому как нужно ловить NumberFormatException в Integer.parseInt
            try{
            v.nextToken();
                v.nextToken(" ");
                     ContentLen = Integer.parseInt( v.nextToken() );
            }catch(Exception e3){}
        }
              }  
            } 
        }
   }
}


Итого загрузка 1мб файла вызывает аллокацию 5мб памяти. Вот серверок-то и дохнет....
100 тредов и "шоб ви жили на один page file"

Резюме: Наличие высокоуровневых языков с GC и библиотек это конечно здорово, но!
результат который вот реально получился тот же примерно что и поймать GPF в С++.
Для нахождения где оно и как оно клинит сервер ушел один день — ровно столько сколько
бы вызвало устранение GPF.

Еще раз ничего личного ни про Java ни про другие фреймворки.
Просто разработка надежного кода занимает ровно то же самое время что с что без.
Глубокое заблуждение что если managed code то типа надежная система автоматом.
Re: Смотрел на Java код. ...много думал.
От: Кодт Россия  
Дата: 29.10.05 08:09
Оценка: +4
Здравствуйте, c-smile, Вы писали:

CS>Итого загрузка 1мб файла вызывает аллокацию 5мб памяти. Вот серверок-то и дохнет....

CS>100 тредов и "шоб ви жили на один page file"

CS>Резюме: Наличие высокоуровневых языков с GC и библиотек это конечно здорово, но!

CS>результат который вот реально получился тот же примерно что и поймать GPF в С++.
CS>Для нахождения где оно и как оно клинит сервер ушел один день — ровно столько сколько
CS>бы вызвало устранение GPF.

CS>Еще раз ничего личного ни про Java ни про другие фреймворки.

CS>Просто разработка надежного кода занимает ровно то же самое время что с что без.
CS>Глубокое заблуждение что если managed code то типа надежная система автоматом.

Тут есть нюанс: система не выдержала стресс-тест, но в комфортных условиях работала бы себе на здоровье.
Кстати говоря, родить такую же фигню на unmanaged — без проблем; точно так же будет жить в комфорте и так же не выдержит стресс.
А вот код с расстрелами памяти — это уже как повезёт, ибо UB.

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

В том же С встал бы выбор: или написать конвейер для посимвольной разборки, или нагородить кучу malloc'ов. Думаю, что лень-матушка его остановила бы. А в С++ — без проблем: строку раз, строку два, вектор строк три... И эта штука будет очень прозрачна для понимания (в отличие от чисто потоковой версии) и столь же прожорлива.
Перекуём баги на фичи!
Re: Смотрел на Java код. ...много думал.
От: Nickolay Ch  
Дата: 29.10.05 09:21
Оценка: +2
Здравствуйте, c-smile, Вы писали:


CS>Вот такой вот показательный пример,


CS>Комментарии в тексте мои.

CS>Внимание! я не критикую автора. Я просто хочу обратить внимание
CS>на то как safe код фактически рушит систему — код работал на клиенте
CS>и возникла потребность перенсти его на сервер. Сервер не сказать
CS>чтобы умер — просто перестал "серверить".

Вообще то, перенос клиентского кода на сервер ни к чему хорошему не приведет(скорее всего), не важно, на чем и как написан код, дело не в managed/unmanaged, а в совершенно разных требованиях предъявляемых к клиентскому м серверному коду.
Немножко странный пример, сродни: взяли иномарку(не повышенной проходимости) и поехали по русской деревне. Ай-ай она застряла на бездорожъе...

CS>Итого загрузка 1мб файла вызывает аллокацию 5мб памяти. Вот серверок-то и дохнет....

CS>100 тредов и "шоб ви жили на один page file"

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

CS>Глубокое заблуждение что если managed code то типа надежная система автоматом.


Автоматом надежных систем не бывает, вроде это и так понятно.
Возвратимся к машинам: дорогая иномарка не избавляет нас от необходимости уметь водить и соблюдать правила, она избавляет от излишнего гемора с постоянными ремонтами мелких и средних поломок, и дает дополнительный комфорт при использовании.
Re: Смотрел на Java код. ...много думал.
От: savaDAN  
Дата: 29.10.05 09:29
Оценка: +2
CS>Внимание! я не критикую автора. Я просто хочу обратить внимание
CS>на то как safe код фактически рушит систему — код работал на клиенте
CS>и возникла потребность перенсти его на сервер. Сервер не сказать
CS>чтобы умер — просто перестал "серверить".
Ага, при этом если бы человек начал писать данный код оптимально, потратив в 2-3 раза времени больше (с учетом отладки и поиска ошибок), то получил бы нагоняй от менеджера за то что занимается gold plating-ом и срывает сроки.

Мораль имхо можно вынести из этой истории одну: каждый код имеет свой scope использования, следовательно не стоит надеятся что код написанный для взаимодействия с пользователем будет также хорошо работать с real-time системами... хотя вроде бы это и так понятно

CS>Резюме: Наличие высокоуровневых языков с GC и библиотек это конечно здорово, но!

CS>результат который вот реально получился тот же примерно что и поймать GPF в С++.
CS>Для нахождения где оно и как оно клинит сервер ушел один день — ровно столько сколько
CS>бы вызвало устранение GPF.
Наличией высокоуровневых библиотек это здорово, потому что сокращает время разработки, позволяет разрабатывать более сложные системы, меньше выполняя закатов солнца вручную, уменьшает количество ошибок.
НО! системы с автоматическим управлением памятью имеют свои ньюансы, которые нужно учитывать при разработке.
Также, нужно четко прописывать scope применения кода.
А уж о том что Sting immutable и о том как правильно их готовить написана целая куча книжек.

CS>Просто разработка надежного кода занимает ровно то же самое время что с что без.

ну не стоит так однозначно! на некоторых задачах быстрее и удобней. на некоторых наоборот.
например в одной из книжек по оптимизации Java автор писал как раз сервер, где основной оптимизацией был уход от String и переход на байты. Быстрее стало в результате на несколько порядков.. но код выглядел...
Смысл2: уровень сложности задачи требует соответствующего уровня разработчика. Опытный разработчик напишет большую и сложную систему на Java/С# быстрее чем например на С, неопытный: на С — вообще не напишет, а на Java\C# напишет чего нить страшное и еле работающее.

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

CS>Глубокое заблуждение что если managed code то типа надежная система автоматом.

Хм, а где вы такое утверждение слышали? я вот в первый раз его встретил в вашем сообщении
... << RSDN@Home 1.1.4 stable rev. 510>>
Re: Смотрел на Java код. ...много думал.
От: iZEN СССР  
Дата: 29.10.05 11:45
Оценка: 2 (2) +3
Здравствуйте, c-smile, Вы писали:


CS>Вот такой вот показательный пример,


CS>Фрагмент (очень неполный) читает нечто по протоколу superset of http


CS>Комментарии в тексте мои.

CS>Внимание! я не критикую автора. Я просто хочу обратить внимание
CS>на то как safe код фактически рушит систему — код работал на клиенте
CS>и возникла потребность перенсти его на сервер. Сервер не сказать
CS>чтобы умер — просто перестал "серверить".

CS>
CS>class ReaderThread extends Thread {
<...>
CS>    public void run () {
<...>
CS>   }
CS>}
CS>

CS>Итого загрузка 1мб файла вызывает аллокацию 5мб памяти. Вот серверок-то и дохнет....
CS>100 тредов и "шоб ви жили на один page file"
Аллокация пустого объекта без методов в памяти Java занимает порядка 8 байт (вместе с RTTI). Если не прав — пусть поправят, но я где-то встретил именно такую цифру и запомнил.

Что касается приведённого кода, то он не оптимален с нескольких точек зрения:
* поток не может быть использован повторно и уничтожается GC при завершении метода run();
* в теле метода run() порождаются новые объекты и не самым качественным образом;
* нет реакции не только на NumberFormatException в Integer.parseInt (что можно было бы объяснить ненужностью этого), но и на ВСЕ(без исключения!) исключения: (catch(Exception e3){})

Для сервера этот код однозначно не годится, так как потребует для своего обслуживания слишком много процессорного времени. Для персоналки — вполне подходит.

CS>Резюме: Наличие высокоуровневых языков с GC и библиотек это конечно здорово, но!

CS>результат который вот реально получился тот же примерно что и поймать GPF в С++. Для нахождения где оно и как оно клинит сервер ушел один день — ровно столько сколько бы вызвало устранение GPF.

Как бы Вам объяснить.
Этот код, как бы он плох не был, не может вызвать GPF и отказ операционной системы, но вполне может привести к временному DoS (отказ в обслуживании), вызванному исчерпанием свободной памяти при массовых запросах на обслуживание. При этом в отличие от систем, написанных на C/C++, краха системы не произойдёт, она лишь остановится на время работы сборщика мусора и рекуперации файла подкачки. Код вполне надёжен, если не признать угрозу DoS.

CS>Просто разработка надежного кода занимает ровно то же самое время что с что без.

Вы не правы.
Всегда разработка надёжного кода требует дополнительного времени.
Чтобы оптимизировать код для сервера, нужно применить совершенно другие техники программирования:
* пулинг потоков обработки запросов;
* повторное использование объектов;
* повышение надёжности синхронизации и защиты объектов;
* выявить узкие места производительности и устранить "бутылочные горлышки" для потоков данных;
* и т.д., и т.п.

Так как критичность работы сервера имеет гораздо важное значение, чем работа персоналки, серверному коду уделяется большее внимание, чем десктопному.
СS>Глубокое заблуждение что если managed code то типа надежная система автоматом.
Управляемый код автоматом решает лишь половину проблем надёжности систем.
Re: Смотрел на Java код. ...много думал.
От: vladserge Россия  
Дата: 29.10.05 15:11
Оценка:
Здравствуйте, c-smile, Вы писали:

Как я с Вами согласен.
И подобная дичь повсеместно, даже (о ужас!) в базовых библиотеках (JDK) и примерах их использования!
С Уважением Сергей Чикирев
Re: Смотрел на Java код. ...много думал.
От: vdimas Россия  
Дата: 29.10.05 15:59
Оценка:
Здравствуйте, c-smile, Вы писали:


Вообще-то, туда просился посимвольный потоковый алгоритм. Вроде это можно было и на Java сделать.
Re: Ответ всем сразу.
От: c-smile Канада http://terrainformatica.com
Дата: 30.10.05 00:14
Оценка: 42 (5) +5 -3
Здравствуйте, c-smile, Вы писали:


Этот код плох. И для клиента и для сервера. По любому 5 мб на один это извиняюсь ... Другого слова у меня нет.

Наличие String.startsWidth конечно радует в "удобной" библиотеке, но
лично меня радует больше наличие "unsafe" strncmpi() которая одна только в приведенном
примере убирает + 2N + 2N требуемой памяти. .

Простую strncmpi можно было бы и написать для данного конкретного контекста руками (три строки), но
мы имеем следующий мифический посыл :

"Наличией высокоуровневых библиотек ... сокращает время разработки, позволяет разрабатывать более сложные системы, меньше выполняя закатов солнца вручную, уменьшает количество ошибок." (с) savaDAN

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

Далее:

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


Смею утверждать следующее: GPF в данном конкретном случае лучше. Он заставляет что-то делать сразу и показывает место где именно это произошло. Сейчас оно молча вешает сервак и заставляет верещать load balancer. При этом никто не понимал что оно и почему оно. Все же вроде работает... Пришлось написать достаточное количество кода для логов, останавливать живой сервер, перезапускать и т.д.
В итоге (работающая система) имеем соизмеримое время разработки что для Java что для C.

Далее:

Вообще то, перенос клиентского кода на сервер ни к чему хорошему не приведет(скорее всего), не важно, на чем и как написан код, дело не в managed/unmanaged, а в совершенно разных требованиях предъявляемых к клиентскому м серверному коду.
(С) Nickolay Ch.


Смею утверждать следущее: если код написан правильно то ему все равно где работать — на сервере или на клиенте — он просто будет работать.
Согласен что "дело не в managed/unmanaged". Все дело в мифах "память больше не ресурс", "наличие высокоуровневых библиотек" и пр. эзотерике. Просто эти мифы сильно понижают планку требований к разработчикам. Особенно в сознании менеджмента который в свою очередь если покупается на такое посещает ту же группу детского сада.
Прошу обратить внимание — я не говорю о том что уровень конкретных разарабтсиков низкий — я говорю о том что мифы создают условия когда профессионалы *вынуждены* писать такое.


Тут на форуме был показательный пример про "Шустрики..."
Графический код написанный с использованием стандартной билиотеки и рекомендованных средств удобного языка
потребовал "недюженной работы мозга" профессионала. В результате по затратам получилось времени больше чем на голимом С и в лоб. Я об этом.
Re[2]: Смотрел на Java код. ...много думал.
От: c-smile Канада http://terrainformatica.com
Дата: 30.10.05 00:51
Оценка: -3 :))
Здравствуйте, vladserge, Вы писали:

V>Здравствуйте, c-smile, Вы писали:


V>Как я с Вами согласен.

V>И подобная дичь повсеместно, даже (о ужас!) в базовых библиотеках (JDK) и примерах их использования!
V>

Угу, вот конфетки из дистрибутива PersonalJava от Sun


    // Щаз, пацаны, мы покажем как писать надежный метод надежной библиотеки. 
    // Вот типа шоб враги, значить, нашу унутренню  minSize (типа Dimension) 
    // грязными руками (омытыми водами Ганга), значить, не похакали мы ея
    // типа скопируем шоб, значить, не напрягать мозг созданием 
    // immutable Dimension класса. Ну типа он же у нас уже есть, фигли тада напрягаться?

    public synchronized Dimension getPreferredSize(int rows, int cols) {
    return new Dimension(minSize);
    }

    // "AWT есть но не работает!"
    // "Та що ви говорите? От дасада... А зато душа в ней гарна, сил нет..."
    // ...
    // "Не... в то место моя щира душа не поместится...."
Re: Смотрел на Java код. ...много думал.
От: alexeiz  
Дата: 30.10.05 01:53
Оценка: +1
Здравствуйте, c-smile, Вы писали:


CS>Вот такой вот показательный пример,


CS>Фрагмент (очень неполный) читает нечто по протоколу superset of http

...
CS>Итого загрузка 1мб файла вызывает аллокацию 5мб памяти. Вот серверок-то и дохнет....
CS>100 тредов и "шоб ви жили на один page file"

Интересно, но там же чтение по строкам. Каждая отдельная строка не больше нескольких десятков байт. Строка испльзуется и сразу выбрасывается, и память сразу становится garbage collectible. Выделение памяти в GC происходит быстро. А в данном случае выделенная память даже не переходит во следующее поколение — GC при первом же проходе её собирает. Поэтому 5мб — это что называется reference set, а не working set.

Коротко живужие объекты — это как раз то, на что затачивается GC. Использовать их в managed коде (будь то Java или .NET) совсем не зазорно. Я бы даже сказал, что другого выбора там вобщем то и нет, так как на стеке объекты создавать нельзя.

Смотрю, я на этот код и ведь ничего особенно криминального в нём не вижу. Ну, используется в нём в пять раз больше памяти, чем в оптимальном варианте, и что? Объекты все короткоживущие. Кроме нагрузки на GC никакого ужерба они не приносят.

Потом мне кажется ты неадыкватно реагируешь на подобные вещи. По сути дела, у вас на сервере обнаружился bottleneck, который вы нашли и пофиксили. Я уверен, что это не первый и не последний. Писать код, чтобы никаких bottleneck'ов не было невозможно. Причем сразу сказать, где этот bottleneck будет, невозможно. Мы сначала пишем код, потом профилируем, потом оптимизируем. Стандартная схема. Я не вижу, как твой пример является чем-то из ряда вон выходящим.

CS>Еще раз ничего личного ни про Java ни про другие фреймворки.

CS>Просто разработка надежного кода занимает ровно то же самое время что с что без.
CS>Глубокое заблуждение что если managed code то типа надежная система автоматом.

Как бы согласен и одновременно не согласен. Естественно, managed code не значит, что система получится надёжной автоматом. Однако, если говорить об уровне абстракции, в варианте "с" она выше, чем в варианте "без". А при более высоком уровне абстракции код писать всё таки легче и надёжнее (вне зависимости от языка программирования). Другое дело, что отдельные места могут потребовать оптимизации. И тогда мы можем в этих конкретных местах уровень абстракции понизить, чтобы добиться требуемой производительности.
Re[2]: Многия знания - многия печали
От: c-smile Канада http://terrainformatica.com
Дата: 30.10.05 02:59
Оценка: +1 :)
Здравствуйте, alexeiz, Вы писали:

A>Здравствуйте, c-smile, Вы писали:



CS>>Вот такой вот показательный пример,


CS>>Фрагмент (очень неполный) читает нечто по протоколу superset of http

A>...
CS>>Итого загрузка 1мб файла вызывает аллокацию 5мб памяти. Вот серверок-то и дохнет....
CS>>100 тредов и "шоб ви жили на один page file"

A>Интересно, но там же чтение по строкам. Каждая отдельная строка не больше нескольких десятков байт. Строка испльзуется и сразу выбрасывается, и память сразу становится garbage collectible. Выделение памяти в GC происходит быстро. А в данном случае выделенная память даже не переходит во следующее поколение — GC при первом же проходе её собирает. Поэтому 5мб — это что называется reference set, а не working set.


Во! Got one more: "GC он умный"

Обрати внимание там стоит такая штука:

class ReaderThread extends Thread {
  public void run ()
  {
  }
}


продолжать надо?


A>Коротко живужие объекты — это как раз то, на что затачивается GC. Использовать их в managed коде (будь то Java или .NET) совсем не зазорно. Я бы даже сказал, что другого выбора там вобщем то и нет, так как на стеке объекты создавать нельзя.


Согласен. Только бы еще флажок бы где у того new ....
new (кылянусь-shortliving, threadlocal-зуб-даю)

Если без приколов то на практике поимели в результате тестов следующее
Execution time:
1 thread per machine — 2 секунды в run().
3 threads per machine — 8.5 секунды в run() для каждой thread (sic!).
Дальше идет суровая экспонента.
На самом деле там еще есть такого рода штуки.

А сервер уходит в глубокий GC c context switching. А внешне все класс — лампады моргают.
Re[3]: Многия знания - многия печали
От: alexeiz  
Дата: 30.10.05 04:42
Оценка: +1
Здравствуйте, c-smile, Вы писали:

CS>Во! Got one more: "GC он умный"


CS>Обрати внимание там стоит такая штука:


CS>
CS>class ReaderThread extends Thread {
CS>  public void run ()
CS>  {
CS>  }
CS>}
      
CS>


CS>продолжать надо?


Может быть в этом и проблема? Создаёте поток на каждый запрос. Это не сильно помогает scalability. Вот цитата из Improving .NET Application Performance and Scalability:

Threading Guidelines
This section discusses guidelines that you can use to help improve threading
efficiency in ASP.NET. The guidelines include the following:
— Tune the thread pool by using the formula to reduce contention.
— Consider minIoThreads and minWorkerThreads for burst load.
Do not create threads on a per-request basis.
— Avoid blocking threads.


A>>Коротко живужие объекты — это как раз то, на что затачивается GC. Использовать их в managed коде (будь то Java или .NET) совсем не зазорно. Я бы даже сказал, что другого выбора там вобщем то и нет, так как на стеке объекты создавать нельзя.


CS>Согласен. Только бы еще флажок бы где у того new ....

CS>new (кылянусь-shortliving, threadlocal-зуб-даю)

Зачем? Для этого у GC есть поколения.

CS>Если без приколов то на практике поимели в результате тестов следующее

CS>Execution time:
CS>1 thread per machine — 2 секунды в run().
CS>3 threads per machine — 8.5 секунды в run() для каждой thread (sic!).
CS>Дальше идет суровая экспонента.
CS>На самом деле там еще есть такого рода штуки.

Даже 2 секунды в run() — это много.

CS>А сервер уходит в глубокий GC c context switching. А внешне все класс — лампады моргают.


Да, я ничего против не имею. Смотреть сколько времени серверное приложение проводит в GC — это первое дело. Если много, то искать, какой @$@#$ там выделяет. Если слишком часто собираются разные поколения, то искать, какой #@$%# выделяет и держит память.

Только вот код, который ты показал — это типичный метод программирования в управляемых средах. За свой опыт я понял, что очень часто совсем не представляешь, сколько же памяти потребляет та или иная операция в .NET. Если можешь оценить на уровне О-больших, то это уже хорошо. Необходимость профилировать выделение памяти в managed code встаёт гораздо чаще чем в native. В этом есть интересный парадокс. Казалось бы, с появлением GC проблем с памятью быть должно меньше. А получается, что появляется нужда отслеживать перевыделение, которое в средах без GC является второстепенной задачей.
Re[4]: Многия знания - многия печали
От: c-smile Канада http://terrainformatica.com
Дата: 30.10.05 07:02
Оценка: :)
Здравствуйте, alexeiz, Вы писали:

A>Здравствуйте, c-smile, Вы писали:


CS>>Во! Got one more: "GC он умный"


CS>>Обрати внимание там стоит такая штука:


CS>>
CS>>class ReaderThread extends Thread {
CS>>  public void run ()
CS>>  {
CS>>  }
CS>>}
      
CS>>


CS>>продолжать надо?


A>Может быть в этом и проблема? Создаёте поток на каждый запрос. Это не сильно помогает scalability. Вот цитата из Improving .NET Application Performance and Scalability:

A>

A>Threading Guidelines
A>This section discusses guidelines that you can use to help improve threading
A>efficiency in ASP.NET. The guidelines include the following:
A>- Tune the thread pool by using the formula to reduce contention.
A>- Consider minIoThreads and minWorkerThreads for burst load.
A>- Do not create threads on a per-request basis.
A>- Avoid blocking threads.


Нет проблема не в этом. (Понятно что thread pool это way to go)
Проблема в том что среди десяти threads появляется одна в которой
выполняется этот вот кусок. И все. Всем привет.
GC начинает останавливать все потоки. Когда они *все* остановились
тогда чистится мусор. Затем вся эта бодяга весело перезапускается.
Тут же выпадая в следующий осадок. Потому как тот IP на котором
работает приведенный фрагмент сидит на жирной трубе.

Как ты сам понимаешь выяснение причины в такого рода ситуациях —
шаманство чистой воды. Там где у тебя бы вывалилось not-enough-memory
этот виртуальный машин будет тужится но жить.
"Та нехай би вин вже помер,'га?"

A>>>Коротко живужие объекты — это как раз то, на что затачивается GC. Использовать их в managed коде (будь то Java или .NET) совсем не зазорно. Я бы даже сказал, что другого выбора там вобщем то и нет, так как на стеке объекты создавать нельзя.


CS>>Согласен. Только бы еще флажок бы где у того new ....

CS>>new (кылянусь-shortliving, threadlocal-зуб-даю)

A>Зачем? Для этого у GC есть поколения.


Есть поколения и что? Не надо останавливать потоки?
Такого чуда имхо еще нет. В Java есть но в специфических продуктах.
В .NET по моему только в 2.0 должно появиться.


CS>>Если без приколов то на практике поимели в результате тестов следующее

CS>>Execution time:
CS>>1 thread per machine — 2 секунды в run().
CS>>3 threads per machine — 8.5 секунды в run() для каждой thread (sic!).
CS>>Дальше идет суровая экспонента.
CS>>На самом деле там еще есть такого рода штуки.

A>Даже 2 секунды в run() — это много.


Это очень хорошо для данной задачи.

A>Только вот код, который ты показал — это типичный метод программирования в управляемых средах.


Именно это я и говорю. Не мудрствуя лукаво берем типовое решение и получаем абздольц на ровном месте.

A>За свой опыт я понял, что очень часто совсем не представляешь, сколько же памяти потребляет та или иная операция в .NET. Если можешь оценить на уровне О-больших, то это уже хорошо. Необходимость профилировать выделение памяти в managed code встаёт гораздо чаще чем в native. В этом есть интересный парадокс. Казалось бы, с появлением GC проблем с памятью быть должно меньше. А получается, что появляется нужда отслеживать перевыделение, которое в средах без GC является второстепенной задачей.


Момент истины. Что и требовалось доказать.
И не надо говорить что программирование в managed environment это для домохозяек.

Отнюдь. (шелестя манжетами).
Re[2]: Ответ всем сразу.
От: Игoрь Украина  
Дата: 30.10.05 08:14
Оценка: +1
Здравствуйте, c-smile, Вы писали:

ИМХО Дело не в Java. Я видел огромное количество серверного неэффективного и ненадежного кода и на С, и на С++. Тут скорее проблема не в языке, а "в головах", то есть людях, пишущих такое.

Но в данном случае ИМХО это Ваша ошибка — не нужно было тащить клиентский код в серверный. Требования к клиентскому коду всегда гораздо мягче, чем к серверному. И никто в здравом уме не будет писать клиента с учетом серверных требований — дороговато выходит. Например, если я знаю, что клиент не будет держать больше 5~10 соединений, то видимо буду создавать по потоку на соединение, где обработка будет синхронной. Зачем мне усложнять себе жизнь и возиться с асинхронностью, следить за возможной дефрагментацией кучи, за скростью выделения памяти?...и т.д. и т.п. Конечно, я не говорю о том, что при написании клиента нужно на все плюнуть и писать спустя рукава, но и писать с учетом серверное специфики тоже не стоит
Re: Смотрел на Java код. ...много думал.
От: _Winnie Россия C++.freerun
Дата: 30.10.05 09:59
Оценка:
здесь
Автор: _Winnie
Дата: 20.10.05
Правильно работающая программа — просто частный случай Undefined Behavior
Re[3]: Ответ всем сразу.
От: vnp  
Дата: 30.10.05 09:59
Оценка:
Здравствуйте, Игoрь, Вы писали:

И>И никто в здравом уме не будет писать клиента с учетом серверных требований — дороговато выходит. Например, если я знаю, что клиент не будет держать больше 5~10 соединений, то видимо буду создавать по потоку на соединение, где обработка будет синхронной.


Правда никто не будет, что ли?
Меня мама с детства учила, что программист должен уметь считать "ноль-один-много". Со скольких соединений начиная станем заморачиваться с асинхронностью? сколько кода уже будет к тому времени написано?

И>Зачем мне усложнять себе жизнь и возиться с асинхронностью, следить за возможной дефрагментацией кучи, за скростью выделения памяти?...и т.д. и т.п.


Вероятно, чтобы карму не испортить. Упростить поддержку, иначе говоря.
Re[2]: Смотрел на Java код. ...много думал.
От: Павел Кузнецов  
Дата: 30.10.05 10:48
Оценка: +1 -1 :)))
savaDAN,

> Опытный разработчик напишет большую и сложную систему на Java/С# быстрее чем например на С


Вот так вот сразу, без конкретизации, о какой именно системе идет речь?.. Немного информации о разработчике тоже бы не повредило, кроме того, что у него есть опыт...
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re[3]: Ответ всем сразу.
От: vladserge Россия  
Дата: 30.10.05 11:05
Оценка:
Здравствуйте, Игoрь, Вы писали:

И>Здравствуйте, c-smile, Вы писали:


И>ИМХО Дело не в Java. Я видел огромное количество серверного неэффективного и ненадежного кода и на С, и на С++. Тут скорее проблема не в языке, а "в головах", то есть людях, пишущих такое.


И>Но в данном случае ИМХО это Ваша ошибка — не нужно было тащить клиентский код в серверный. Требования к клиентскому коду всегда гораздо мягче, чем к серверному. И никто в здравом уме не будет писать клиента с учетом серверных требований — дороговато выходит.


почему всеравно писать приходится и серверный и клиентский код. не проще один раз написать и если оно заработает на сервере то разве небудет работать на клиенте?

И>Например, если я знаю, что клиент не будет держать больше 5~10 соединений, то видимо буду создавать по потоку на соединение, где обработка будет синхронной. Зачем мне усложнять себе жизнь и


типа, нафига головой думать, мне не за это плотют
С Уважением Сергей Чикирев
Re[2]: Ответ всем сразу.
От: Nickolay Ch  
Дата: 30.10.05 13:40
Оценка:
CS>Смею утверждать следущее: если код написан правильно то ему все равно где работать — на сервере или на клиенте — он просто будет работать.
CS>Согласен что "дело не в managed/unmanaged". Все дело в мифах "память больше не ресурс", "наличие высокоуровневых библиотек" и пр. эзотерике.
Смею утвержадать, что код должен писаться исходя из задачи, абсолютнов не бывает, уже не раз писал.
Re[4]: Ответ всем сразу.
От: Игoрь Украина  
Дата: 30.10.05 15:21
Оценка: +3
Здравствуйте, vnp, Вы писали:

vnp>Правда никто не будет, что ли?

vnp>Меня мама с детства учила, что программист должен уметь считать "ноль-один-много".
Повезло Вам с мамой.
vnp>Со скольких соединений начиная станем заморачиваться с асинхронностью? сколько кода уже будет к тому времени написано?
Я не очень люблю рассуждать о сферическом коне в вакууме. Но для типичного клиентского приложения 10 соединений это верхний предел (понятно, что бывают и исключения). А принцип выбора у меня простой. Анализирую требования к приложению и специфику его использования. На основании этой информации делаю оценку средней и пиковой нагрузок. А затем пытаюсь подобрать такую модель, которая способна будет выдержать нагрузку где-то на порядок больше. Скажем, для нашего коня в вакууме в среднем будет где-то 3~4 соединения, а пик ~10. В таком случае поток на соединение вполне катит. Понятно, что для высокопроизводительных серверов нужно сразу выжимать максимум и сделать с запасом на порядок не получится.
Вообще не понимаю о чем Вы спорите, специфика клиентских и серверных приложений серьезно отличается.

И>>Зачем мне усложнять себе жизнь и возиться с асинхронностью, следить за возможной дефрагментацией кучи, за скростью выделения памяти?...и т.д. и т.п.

vnp>Вероятно, чтобы карму не испортить.
А Вас мама не учила, что карма, еще бубен — не наши термины?

vnp>Упростить поддержку, иначе говоря.

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

Когда-то я учавствовал в одном проекте, где главной целью поставили универсальность и обобщенность интерфейсов. Когда я спрашивал, а нафига это? Мне отвечали: "А вдруг кому-то захочется вот так сделать." Ох как я тогда наматюкался и наплевался... После этого я для себя решил, что все хорошо в меру, если нужно спроектировать подводную лодку, то не стоит в нее закладывать возможность летать — ничего хорошего из этого не выйдет, получим очередного "ужа с ежом". Поэтому, если проектируем клиента, то не стоит в него закладывать возможность в дальнейшем стать сервером.

ЗЫ
Маме привет!
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.