Re[4]: Ответ всем сразу.
От: Игoрь Украина  
Дата: 30.10.05 15:28
Оценка:
Здравствуйте, vladserge, Вы писали:

V>Здравствуйте, Игoрь, Вы писали:


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


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


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


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

Вообще-то я говорил о другой ситуации — перенос кода с клиентской части на серверную. Что касается Вашего случая... тяжело вот так обобщенно ответить, все зависит от требований. Лично мне ни разу не приходилось что-то подобное делать. Если Вы знаете такого рода open source проекты, киньте ссылки я бы с удовольствием посмотрел. Достаточно часто сервер затачивается под конкретную ОС для достижения лучшей производительности, в то время как клиентов стараются делать кроссплатформенными...

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


V>типа, нафига головой думать, мне не за это плотют

Думать нужно, но не стоит пытаться делать каждую фичу супер навороченной — это никому не нужно и никто не оценит, только позже поимеете проблем на этапе тестирования и сопровождения.
Re: Смотрел на Java код. ...много думал.
От: ie Россия http://ziez.blogspot.com/
Дата: 30.10.05 16:12
Оценка: -1
Смотрел код индусов... много думал.
Вот Ваш пост из той же оперы.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Превратим окружающую нас среду в воскресенье.
Re[2]: Смотрел на Java код. ...много думал.
От: c-smile Канада http://terrainformatica.com
Дата: 30.10.05 17:24
Оценка:
Здравствуйте, ie, Вы писали:

ie>Смотрел код индусов... много думал.

ie>Вот Ваш пост из той же оперы.

Имею другое мнение здесь присутвующих:

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

Re[3]: Ответ всем сразу.
От: c-smile Канада http://terrainformatica.com
Дата: 30.10.05 17:38
Оценка: 2 (2) +1 -1
Здравствуйте, Nickolay Ch, Вы писали:

CS>>Смею утверждать следущее: если код написан правильно то ему все равно где работать — на сервере или на клиенте — он просто будет работать.

CS>>Согласен что "дело не в managed/unmanaged". Все дело в мифах "память больше не ресурс", "наличие высокоуровневых библиотек" и пр. эзотерике.
NC>Смею утвержадать, что код должен писаться исходя из задачи, абсолютнов не бывает, уже не раз писал.

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

Ну вот пример мой htmlayout — это UI компонента чистой воды, ведь так?

Пришли господа-товарищи и сказали хотим на сервере из html pdf делать.
И делают. Делов было на три дня для них.

Абсолютов, да — не бывает и также объять необъятное сложно.

Писать эффективный код экономически целесообразно. Но это песня для отдельного
топика — когда, кем и где.
Re[3]: Смотрел на Java код. ...много думал.
От: VladD2 Российская Империя www.nemerle.org
Дата: 30.10.05 18:30
Оценка: -3
Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Вот так вот сразу, без конкретизации, о какой именно системе идет речь?.. Немного информации о разработчике тоже бы не повредило, кроме того, что у него есть опыт...


С почти сабсэт от C#, так что ерунду говоришь. Тут достаточно информации о том что система большая и сложная.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Смотрел на Java код. ...много думал.
От: VladD2 Российская Империя www.nemerle.org
Дата: 30.10.05 18:30
Оценка: +2 :)
Здравствуйте, c-smile, Вы писали:


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


CS>

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

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

CS>    // "AWT есть но не работает!"
CS>    // "Та що ви говорите? От дасада... А зато душа в ней гарна, сил нет..."
CS>    // ...
CS>    // "Не... в то место моя щира душа не поместится...."
CS>


Изумительный пример мировозрения битовыжимателей. Типа не потимально!!! Объект лишний создают!!! Поибивалбы...

В условиях Явы это единственно верный выход. Типы то опчти все ссылочные. Так что отдать внутенний объект == послать на... всю инкапсуляцию.

Медленно говоришь? Ну, что же подождем Явы 6 (1.6) и проверим насколько это медленно и кто был прав. Думаю, прав был тот кто написал этогт код, так проблемы производительности вызванные подобными решениями дожен решать компилтор, а плевать на инкапсуляцию все же не стоит.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Смотрел на Java код. ...много думал.
От: c-smile Канада http://terrainformatica.com
Дата: 30.10.05 20:53
Оценка: :)))
Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Павел Кузнецов, Вы писали:


ПК>>Вот так вот сразу, без конкретизации, о какой именно системе идет речь?.. Немного информации о разработчике тоже бы не повредило, кроме того, что у него есть опыт...


VD>С почти сабсэт от C#, так что ерунду говоришь. Тут достаточно информации о том что система большая и сложная.


Ну здрастье, Настя!

Это умозаключение произошло в результате
"Пописал на С++... долго думал",
я так понимаю.

Или давай тогда колись как эта мысль тебе в голову пришла.
Re[4]: Смотрел на Java код. ...много думал.
От: c-smile Канада http://terrainformatica.com
Дата: 30.10.05 21:01
Оценка: +1 :))) :))
Здравствуйте, VladD2, Вы писали:

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



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


CS>>

CS>>    // "AWT есть но не работает!"
CS>>    // "Та що ви говорите? От дасада... А зато душа в ней гарна, сил нет..."
CS>>    // ...
CS>>    // "Не... в то место моя щира душа не поместится...."
CS>>


VD>Изумительный пример мировозрения битовыжимателей. Типа не потимально!!! Объект лишний создают!!! Поибивалбы...




"Машина была как настоящая но не ехала"

VD>В условиях Явы это единственно верный выход. Типы то опчти все ссылочные. Так что отдать внутенний объект == послать на... всю инкапсуляцию.


А что нельзя ссылочный объект сделать read-only для снаружи?

VD>Медленно говоришь? Ну, что же подождем Явы 6 (1.6) ...


Влад, я уже этот форум читаю года четыре. И вот это твой оптимизм "подождем светлого будущего..."
просто перманентно греет душу.

Как сказал великий Сальватор Еао:

"Коммунист — коммуниздь!"

Миру-мир!
Re[5]: Смотрел на Java код. ...много думал.
От: VladD2 Российская Империя www.nemerle.org
Дата: 30.10.05 23:43
Оценка:
Здравствуйте, c-smile, Вы писали:

CS>Ну здрастье, Настя!


Так ты девочка !

CS>Или давай тогда колись как эта мысль тебе в голову пришла.


Да как бы писал на обоих не по одному году.
По большому счету кроме препроцессора у С особо уникального ничено не увидел. Все остальное или 1 в один повтояется или чуть по другому, но без особых проблем. Шарп в ансэфе — это почти чистый С. Ну, разве что с пребабахами для интеграции с управляемыми данными.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Смотрел на Java код. ...много думал.
От: VladD2 Российская Империя www.nemerle.org
Дата: 30.10.05 23:43
Оценка: 14 (3) +1
Здравствуйте, c-smile, Вы писали:

CS>А что нельзя ссылочный объект сделать read-only для снаружи?


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

Приведенный тобой паттерн довольно распространент.

VD>>Медленно говоришь? Ну, что же подождем Явы 6 (1.6) ...


CS> Влад, я уже этот форум читаю года четыре. И вот это твой оптимизм "подождем светлого будущего..."

CS>просто перманентно греет душу.

Я не оптимист. Я осведомленный писимист.

http://www-128.ibm.com/developerworks/java/library/j-jtp09275.html

Выделение памяти в стеке
C++ дает программистам выбор между размещением объектов в куче или в стеке. Размещение в стеке эффективнее: выделение памяти дешевле, освобождение совсем ничего не стоит, а язык предоставляет поддержку при разметке сроков жизни объектов, снижая риск забыть освободить объект. С другой стороны, в C++ нужно быть очень внимательным при публикации или совместном использовании ссылок на размещенные в стеке объекты, поскольку они автоматически освобождаются при раскрутке фрейма стека, что приводит к появлению "висячих" указателей.
Еще одно достоинство размещения в стеке состоит в том, что оно куда лучше работает с кешем. На современных процессорах стоимость промаха мимо кеша весьма существенна, так что если язык и runtime могут помочь программе достичь лучшей локальности данных, производительность также повысится. Вершина стека в кеше практически всегда "горячая", а вершина кучи – "холодная" (поскольку с момента последнего использования памяти, скорее всего, прошло немало времени). В результате размещение объекта в куче скорее приведет к большему числу промахов мимо Кеша, чем размещение объекта в стеке.
Что еще хуже, промах мимо кеша при размещении объекта в куче приводит к весьма грязной работе с памятью. При выделении памяти из кучи содержание этой памяти является мусором – битами, оставшимися с момента последнего использования памяти. При выделении не хранящегося в кеше блока памяти из кучи, исполнение приостановится на время переноса содержимого этой памяти в кеш. Затем эти значения будут немедленно переписаны нулями или другими исходными значениями. Все это вместе означает большой объем напрасной работы с памятью (некоторые процессоры, например, Azul Vega, аппаратно ускоряют выделение памяти из кучи).
Escape-анализ
Язык Java не предлагает никакого способа явно разместить объект в стеке, но это не мешает JVM при случае использовать размещение в стеке. JVM могут использовать технику, именуемую escape-анализом (escape analysis), который может определить, что определенные объекты остаются прикованными к определенному потоку на весь срок жизни, и что этот срок жизни ограничен сроком жизни данного фрейма стека. Такие объекты можно безопасно размещать в стеке вместо кучи. Даже лучше, в случае мелких объектов, JVM может полностью избавиться от выделения памяти и просто размещать поля объектов в регистрах.
Листинг 2 показывает пример применения escape-анализа. Метод Component.getLocation() создает защитную копию поля location, так что вызывающая сторона не может случайно изменить текущее расположение компонента. Вызов getDistanceFrom() сперва получает местоположение другого компонента (что включает создание объекта), а затем использует поля x и y объекта, возвращаемого getLocation(), для вычисления расстояния между двумя экземплярами компонентов.
Листинг 2.

public class Point 
{
  private int x, y;

  public Point(int x, int y) 
  {
    this.x = x; this.y = y;
  }

  public Point(Point p) { this(p.x, p.y); }
  public int getX() { return x; }
  public int getY() { return y; }
  public void setX(int newValue) { x = newValue; }
  public void setY(int newValue) { y = newValue; }
}

public class Component 
{
  private Point location;

  public Point getLocation() { return new Point(location); }

  public double getDistanceFrom(Component other) 
  {
    Point otherLocation = other.getLocation();
    int deltaX = otherLocation.getX() - location.getX();
    int deltaY = otherLocation.getY() - location.getY();

    return Math.sqrt(deltaX*deltaX + deltaY*deltaY);
  }
}


Метод getLocation() не знает, что вызывающая сторона собирается делать с возвращаемым им Point; она может удерживать ссылку на него, например, поместив ее в коллекцию, так что getLocation() написан в безопасной манере. Но в этом примере getDistanceFrom() не собирается модифицировать получаемые объекты или запоминать ссылки на них. Он просто собирается ненадолго задействовать Point, а затем избавиться от него, что в данном случае выглядит как разбазаривание ресурсов.
Хорошая JVM может разобраться в происходящем и избавиться от размещения защитной копии. Сначала вместо вызова getLocation() будет подставлено (inlined) тело этого метода, то же будет сделано с вызовами getX() и getY(), в результате чего getDistanceFrom() станет выглядеть так, как показано в листинге 3.
Листинг 3.
public double getDistanceFrom(Component other) 
{
  Point otherLocation = new Point(other.x, other.y);
  int deltaX = otherLocation.x - location.x;
  int deltaY = otherLocation.y - location.y;

  return Math.sqrt(deltaX*deltaX + deltaY*deltaY);
}

Здесь escape-анализ может показать, что объект, создаваемый в первой строке, никогда не покинет своего базового блока и что getDistanceFrom() никогда не изменяет состояние компонента other (под "покинет" имеется в виду то, что ссылка на него не хранится в куче и не передается неизвестному коду, который может удерживать копию). При том, что Point действительно используется только в одном потоке и его время жизни, как известно, ограничено базовым блоком, в котором он размещен, он может быть либо размещен в стеке, либо полностью соптимизирован, как показано в листинге 4.
Листинг 4.
public double getDistanceFrom(Component other) 
{
  int tempX = other.x, tempY = other.y;
  int deltaX = tempX - location.x;
  int deltaY = tempY - location.y;
  return Math.sqrt(deltaX*deltaX + deltaY*deltaY);
}

В результате мы получаем точно такую же производительность, как если бы все поля были публичными, но с сохранением безопасности, предоставляемой инкапсуляцией и защитным копированием (и остальными техниками безопасного программирования).
Escape-анализ в Mustang
Escape-анализ – это оптимизация, о которой говорилось уже давно, и вот, наконец, она здесь – текущие версии Mustang (Java SE 6) могут выполнять escape-анализ и конвертировать выделение памяти в куче в выделение памяти в стеке (или просто избавляться от выделения памяти) там, где это возможно. Использование escape-анализа для устранения некоторых распределений памяти приводит к еще большему ускорению работы с памятью, снижению расхода памяти и уменьшению количества промахов мимо кеша. Кроме того, это снижает нагрузку на сборщик мусора и позволяет реже производить сборку.
Заключение
JVM удивительно хорошо делают вещи, которые раньше были полностью отданы на откуп разработчику. Позволяя JVM выбирать между выделением памяти в куче и в стеке, можно получить преимущества производительности выделения памяти в стеке, не заставляя программиста мучаться с выбором.

Brian Goetz

... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Смотрел на Java код. ...много думал.
От: Павел Кузнецов  
Дата: 31.10.05 01:44
Оценка: 12 (1) +1 -2
VladD2,

> <...> JVM могут использовать технику, именуемую escape-анализом (escape analysis), который может определить, что определенные объекты остаются прикованными к определенному потоку на весь срок жизни, и что этот срок жизни ограничен сроком жизни данного фрейма стека <...>


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

Quantifying the Performance of Garbage Collection vs. Explicit Memory Management:

runtime performance of the best-performing garbage collector is competitive with explicit memory management when given enough memory. In particular, when garbage collection has five times as much memory as required, its runtime performance matches or slightly exceeds that of explicit memory management. However, garbage collection’s performance degrades substantially when it must use smaller heaps. With three times as much memory, it runs 17% slower on average, and with twice as much memory, it runs 70% slower. Garbage collection also is more susceptible to paging when physical memory is scarce. In such conditions, all of the garbage collectors we examine here suffer order-of-magnitude performance penalties relative to explicit memory management.


И это сравнение с достаточно старым алгоритмом Lea, а не с чем-нибудь новым типа Hoard, в присутствии множества параллельных потоков исполнения, как было в случае, описанном c-smile...
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re[3]: Смотрел на Java код. ...много думал.
От: ie Россия http://ziez.blogspot.com/
Дата: 31.10.05 02:37
Оценка:
Здравствуйте, c-smile, Вы писали:

CS>Здравствуйте, ie, Вы писали:


ie>>Смотрел код индусов... много думал.

ie>>Вот Ваш пост из той же оперы.

CS>Имею другое мнение здесь присутвующих:

CS>

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


ИМХО, это типичное мнение людей до конца непонимающих назначение управляемых сред. Неужели у Вас есть мнение, что приведенный код — это эталон управляемого кода?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Превратим окружающую нас среду в воскресенье.
Re[6]: А скажи ка мне "писимист" песимисту...
От: c-smile Канада http://terrainformatica.com
Дата: 31.10.05 02:48
Оценка:
Здравствуйте, VladD2, Вы писали:


Зачем все эти пляски с бубном?

Чем этот самый escape analysys лучше проверенного веками const?

Когда закончится это программирование на кофейной гущще когда
скорость выполнения программы зависит от положения Сатурна в момент исполнения?

public class Component 
{
  private Point location;

  public const Point getLocation() { return location; }

  public double getDistanceFrom(const Component other) 
  {
    const Point otherLocation = other.getLocation();
    int deltaX = otherLocation.getX() - location.getX();
    int deltaY = otherLocation.getY() - location.getY();

    return Math.sqrt(deltaX*deltaX + deltaY*deltaY);
  }
}



Что может быть проще?
Re[4]: Смотрел на Java код. ...много думал.
От: c-smile Канада http://terrainformatica.com
Дата: 31.10.05 05:45
Оценка: :)
Здравствуйте, ie, Вы писали:

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


CS>>Здравствуйте, ie, Вы писали:


ie>>>Смотрел код индусов... много думал.

ie>>>Вот Ваш пост из той же оперы.

CS>>Имею другое мнение здесь присутвующих:

CS>>

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


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


Свое мнение я уже изложил.

Это вот родной код фирмы Sun:

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


Вопрос: означенная фирма до конца ли понимает "назначение управляемых сред"? Как думаешь?

ПыСы: Там еще кстати замечательное такое слово synchronized используется. "Для знатоков штучка".
Re: Смотрел на Java код. ...много думал.
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 31.10.05 08:05
Оценка:
Здравствуйте, c-smile, Вы писали:

CS>Резюме:...


Просто в Java нет value-типов. Отсюда все эти оверхедные но вынужденно необходимые new, new, new... на каждый чих.
Re[2]: Смотрел на Java код. ...много думал.
От: Petrovich_Alex  
Дата: 31.10.05 08:13
Оценка:
Здравствуйте, Сергей Губанов, Вы писали:

СГ>Просто в Java нет value-типов. Отсюда все эти оверхедные но вынужденно необходимые new, new, new... на каждый чих.


Просто в Java есть примитивные типы. "Отсюда все эти оверхедные но вынужденно необходимые new, new, new... на каждый чих."
... << RSDN@Home 1.1.4 stable rev. 510>>
Re[3]: Смотрел на Java код. ...много думал.
От: savaDAN  
Дата: 31.10.05 08:16
Оценка: +1
>> Опытный разработчик напишет большую и сложную систему на Java/С# быстрее чем например на С
ПК>Вот так вот сразу, без конкретизации, о какой именно системе идет речь?.. Немного информации о разработчике тоже бы не повредило, кроме того, что у него есть опыт...
опытный и талантлиовый разработчик напишет большую и сложную систему на любом языке, однако, тот же С#\Java ему поможет следующим (по сравнению с С):
1. классы — легче проектировать
2. управление памятью — меньше багов
3. большая стандартная библиотека — меньше кода писать.
т.е. усилий все таки придется потратить меньше.

А вообще квотированную вами фразу желательно рассматривать в общем контексте моего ответа господину c-smile-у.
... << RSDN@Home 1.1.4 stable rev. 510>>
Re[7]: Смотрел на Java код. ...много думал.
От: VladD2 Российская Империя www.nemerle.org
Дата: 31.10.05 15:32
Оценка:
Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Это все, конечно, здорово, но пока что даже в области значительно более проработанной, а именно GC, автоматика достаточно серьезно отстает от грамотного ручного управления памятью, если в первом случае не дать очень существенный запас по памяти.


Все относительно. Если не брать ручных оптимизаций для конкретных случаев (вроде пулов), то стандартные хипы ОС обычно проигрыват ЖЦ. Причем проигрыш этот не линейный. Чем больше фрагментируется куча, тем больше этот проигрыш.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: А скажи ка мне "писимист" песимисту...
От: VladD2 Российская Империя www.nemerle.org
Дата: 31.10.05 15:32
Оценка:
Здравствуйте, c-smile, Вы писали:

CS>Зачем все эти пляски с бубном?


CS>Чем этот самый escape analysys лучше проверенного веками const?


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

К тому же const в С++ очень условная вещь. На него можно начьхать. А управляемых средах этот const пришлось бы распростронять на всю виртуальную машину. А это задача не тривиальная.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Ответ всем сразу.
От: Nickolay Ch  
Дата: 31.10.05 17:23
Оценка:
CS>Извиняюсь но как минимум код должен разрабатываться с применением инженерной совести.
CS>А специфика задачи...

Ну вот опять совесть полезла. Что такое совестьЮ тогда давайте пофлеймим, только уж лучше в Священных войнах.
Писать надо так, как целесообразней, сиречь, так, что быстрее привелет нас к результатую. Целесообразность целиком зависит от задачи.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.