Компания Parallel Universe объявила (http://blog.paralleluniverse.co/post/26909672264/on-distribu...) об открытии под лицензией LGPLv3 системы распределённой памяти Galaxy (http://puniverse.github.com/galaxy/) (in-memory data-grid), предназначенной для создания распределённых приложений, выполняемых на нескольких узлах, обрабатывающих единый массив данных. Galaxy берёт на себя функции распределения объектов данных, хранимых в виде байтового массива, между различными узлами кластера, создавая для запущенного на нескольких узлах приложения иллюзию, что работа ведётся с монолитной областью памяти.
При организации работы распределённой памяти возникает необходимость решения трёх проблем: выбор на каком узле потребуется та или иная порция данных, в ситуации когда все данные не умещаются в памяти одного узла; обеспечение непротиворечивости данных, при том, что один и тот же блок может одновременно обрабатываться и дублироваться на нескольких узлах; защита от потери/повреждения данных в случае сбоя узла кластера или возникновении сетевых проблем.
Отличительной чертой Galaxy является способ привязки данных к узлам кластера, на которых запущены процессы-обработчики. Вместо использования хэшей Galaxy реализует метод динамического перемещения объектов от одного узла к другому по мере возникновения в них необходимости, используя протокол похожий по своей сути на технику обеспечения согласованности содержимого внутреннего кэша CPU. Подобный подход позволяет использовать Galaxy в приложениях с предсказуемой логикой обращения к данным, поведение которых согласуется с определёнными вероятностными метриками, позволяющими предположить, что расположенные рядом данные скорее всего будут обработаны вместе, чем данные находящиеся далеко друг от друга.Для оптимизации производительности каждый объект данных ассоциируется с определённым узлом-владельцем, который выбирается по степени интенсивности работы с объектом данных. Когда с объектом работает узел владелец данные обрабатываются локально с минимальными задержками, при обращении к данному блоку с другого узла выполняются дополнительные действия по синхронизации состояния между узлами. В пределах всего кластера гарантируется согласованность всех данных, например, если блок Б изменён после изменения блока А, то гарантируется, что ни на одном узле не может оказаться новый блок А и старый Б. Для обеспечения отказоустойчивости, данные могут дублироваться на дополнительных узлах.
Galaxy не является традиционным хранилищем данных в формате ключ/значения, но при желании может быть использован в качестве низкоуровневого базиса для создания подобных систем и произвольных распределённых структур данных. Кроме того, Galaxy предоставляет средства для обмена сообщениями с гарантированной доставкой и сохранением порядка следования, а также обеспечивает работу сервиса по управлению конфигурацией кластера. Для управления кластером поддерживается интеграция с системами ZooKeeper и JGroups. Для обеспечения постоянного хранения содержимого распределённой памяти может быть использована БД BerkeleyDB и любые SQL СУБД. Код компонентов Galaxy написан (https://github.com/puniverse/galaxy) на языке Java.
URL: http://blog.paralleluniverse.co/post/26909672264/on-distribu...
Новость: http://www.opennet.ru/opennews/art.shtml?num=34313
> Код компонентов Galaxy написан на языке Java.Последнее предложение перечекнула всю статью. Хоть с конца текст новости читай. Обидно...
Автор, в чём проблема-то? "Потому что здесь так принято"? Всякий раз когда на opennet упоминается Java находятся желающие поплеваться в неё. Чем Вам Java не угодила, замечательный и простой язык, который легко выучить, а людей, знающих СИ от и до, в мире всего несколько человек. Превосходные библиотеки классов, переносимость, встроенные средства параллельного программирования, туевы хучи библиотек. Медленно работает, ест память? Лекарство от криворукости — умные книжки, особливо Джошуа Блоха. У каждого языка свои особенности и чтобы не гадить в память и не занимать процессор нужно их знать и понимать.
У меня знакомая — аспирант кафедры системного программирования — пишет в цикле:
String s = new String();
s = "data # " + arg[0] + " " + arg[1];
потом ругается, что ей Java не нравится из-за тормознутости.
Ой, «набигут» сейчас толпы хелловурлдщиков и скрипт-кидди, разбрасывая слюну, рассказывать какая Java плохая…
> Ой, «набигут» сейчас толпы хелловурлдщиков и скрипт-кидди, разбрасывая слюну, рассказывать какая Java плохая…Эти как раз жабу любят, потому что ничего кроме нее осилить не смогли.
> Медленно работает, ест память? Лекарство от криворукости — умные книжки, особливо Джошуа Блоха.Где я возьму столько умных книжек, в том числе и Джошуа Блоха, чтобы послать их каждому криворукому жабакодеру, с поделиями которого приходится работать?
Все правильно сказал. Легкий в освоении, красивый язык -> низкий порог вхождения -> толпы говнокодеров -> проектов много а толку мало. Профи обижаются...
И это не считая тормозов и кушанья памяти... с этим все профи уже смерились и забываются иногда до того что начинают с пеной у рта доказывать что это не так :-)
> Все правильно сказал. Легкий в освоении, красивый язык -> низкий порог вхождения
> -> толпы гoвнокодеров -> проектов много а толку мало. Профи обижаются...По сути дела, java - это нишевый аналог PHP.
>> Все правильно сказал. Легкий в освоении, красивый язык -> низкий порог вхождения
>> -> толпы гoвнокодеров -> проектов много а толку мало. Профи обижаются...
> По сути дела, java - это нишевый аналог PHP.Гхм .... вообще-то сравнивать Java и PHP некорректно.
PHP - вообще говоря собранная на коленке скриптомолотилка, а Java - полноценный язык, который если и сравнивать, то уже явно не с PHP
К слову если брать Web приложения. то PHP даже со всеми акселераторами медленне (особенно это заметно на сложных приложениях) контейнера сервлетов аля TomCat.
> Гхм .... вообще-то сравнивать Java и PHP некорректно.
> PHP - вообще говоря собранная на коленке скриптомолотилка, а Java - полноценный язык, который если и сравнивать, то уже явно не с PHPС тем же успехом можно утверждать, что
> Java - вообще говоря собранная на коленке скриптомолотилка, а PHP - полноценный язык, который если и сравнивать, то уже явно не с JavaСуть утверждения от этого не изменится =)
> К слову если брать Web приложения. то PHP даже со всеми акселераторами медленне (особенно это заметно на сложных приложениях) контейнера сервлетов аля TomCat.Очень сложно работать медленнее томката. Пых с этим обычно не справляется. Даже на питоне это порой бывает трудно обеспечить.
> Очень сложно работать медленнее томката. Пых с этим обычно не справляется. Даже
> на питоне это порой бывает трудно обеспечить.Спасибо, посмелся от души.
А Вы осильте программирование сервлетов да настройку TomCat и сравните .. если руки не растут из пятой точки, то получите быстрее даже, чем с eaccelerator.
Также задам простой вопрос: если PHP так хорош, то зачем тод-же Facebook вложит кучу сил и денег в разработку конвертера PHP -> C++ ?
Обратите внимание: не в PHP -> Java
:-D Вот это уже реально смешно.
По сути дела, Java - это Cobol.
Код, написанный на C, можно заюзать в проектах на других языках программирования, код на Java - увы, только в Java проектах.
Зато в Java-проекте можно заюзать код написанный на любом языке :)
Это !=
>а людей, знающих СИ от и до, в мире всего несколько человекспасибо, посмеялся с утра.
тото подавляющее число пакетов в репе дистра на сях и плюсах написана. наверное их все 2-3 человека пишут, гггг, "суперкодер" и "человек-страуструп"
Он просто не отличает чистый си от плюсов. Или я слишком хорошего мнения о людях.
> s = "data # " + arg[0] + " " + arg[1];Конкретно тут на современной яве быстроты не особо достигнешь.
Вот и живой пример.
Читать надо было сюды:
>...пишет в цикле:
>String s = new String();.
Вот и живой пример, незнающий что оператор + медленнее метода append()
Если не разбираетесь в вопросе лучше помолчать - умнее казаться будете.
Пройдя по этой ссылке http://docs.oracle.com/javase/6/docs/api/java/lang/String.html любой легко убедиться что класс String не содержит метода append
Предположим что вы имели в виду StringBuilder, он действительно содержит метод append, но только в данном случае его лучше не использовать, производительность просядет в разы.Основная ошибка в приведённом коде - бесполезная инициализация строковой переменной, т.е. написать следовало
либо так
String string;
for (...) {
...
string = "data # " + arg[0] + " " + arg[1];
...
}либо так
for (...) {
...
String string = "data # " + arg[0] + " " + arg[1];
...
}
>Если не разбираетесь в вопросе лучше помолчать - умнее казаться будете.Вот это в первую очередь к Вам и относится :)
А StringBuilder вообще зачем по - вашему нужен?А теперь внимание, ВНЕЗАПНО, внутри JVM конструкция вида str1 + str2 преобразуется в new StringBuilder(str1).append(str2).toString()
"+" это только лишь синтактический сахар.
Именно поэтому конкатенация двух строк плюсом это нормально, а в цикле будет создан миллион ненужных StringBuilder'ов.
Ну что с него взять, вероятно преподаватель.))) Отожгли оба но аноним ошибся больше. И так Аноним 2 бала. piteri 3 с плюсом (за все же поверхностное знание о чем идет речь).
> Ну что с него взять, вероятно преподаватель.))) Отожгли оба но аноним ошибся
> больше. И так Аноним 2 бала. piteri 3 с плюсом (за
> все же поверхностное знание о чем идет речь).Где именно я показал "поверхностные знания", разрешите уточнить?
перечитал свой пост, вопрос снят.В оправдание своей описки могу сказать, что вполне можно придумать тесткейз где сложение строк отработает быстрее чем стрингбилдер, но это исключительно оптимизации в жвм.
+ Если оптимизация действительно нужна и цикл предположительно выполняется не малое количество итераций, то существенно ускорить процесс можно вынеся StringBuilder (по факту после компиляции он будет создаваться в каждой итерации) за цикл:StringBuilder sb = new StringBuiler();
for (...) {
...
sb.append("data # ").append(arg[0]).append(" ").append(arg[1]);
string = sb.toString();
sb.setLength(0);
...
}Таким образом мы как минимум уберем создание одного промежуточного массива внутри sb на каждую итерацию и вероятно очень существенно сократим количество расширение этого массива в процессе добавления туда данных + на каждую итерацию мы убираем создание StringBuilder. В идеале, возможно в схожих ситуациях вообще можно отказаться от типа String. Так как при каждом sb.toString() будет создаваться копия массива с символами, что в самом конечном итоге приводит к лишнему использованию кэша процессора, не говоря об дополнительных операциях копирования.
Ну не оправдывайтесь, тест провалили. Касательно операторов, все зависит от компилятора, в байт-коде подобных операторов нет. Домашнее задание: сравните с помощью дизассемблера код полученный в результате компиляции ECJ (Eclipse compiler for java) и с помощью javac.Отступ. На C++ можно тоже очень медленную программу написать если на каждый чих создавать/уничтожать объект оператором new/delete. В Java такой подход работает очень шустро в C++ очень медленно (в зависимости еще от компиляторов конечно). Но в общем это сказывается на отзывчивости. Так в Java объекты на практике возможно (в зависимости от примера) будут удалены в момент простоя (я так вообщем, понятно, вариантов множество как и вариантов реализаций виртуальных машин и т.п., но тут лекцию не устроишь), тогда как в C++ вероятно удаление объектов будет отрабатывать в основном потоке выполнения. Не холивара ради, C++ прекрасный язык, если что и у него как и Java есть свои особенности.
> Отступ. На C++ можно тоже очень медленную программу написать если на каждый
> чих создавать/уничтожать объект оператором new/delete. В Java такой подход работает очень
> шустро в C++ очень медленно (в зависимости еще от компиляторов конечно).Если у Вас система создает\уничтожает много объектов - напишите свою собственную реализацию new\delete использовав slab аллокацию объектов и Ваша медленная программа станет настолько быстрой, что никакая жаба не угонится.
То что я пытался донести, Вы не поняли.
>Не холивара ради, C++ прекрасный язык, если что и у него как и Java есть свои особенности.Главная особенность C++ :
«Я придумал термин „объектно-ориентированный“, но я вовсе не имел в виду C++.»
Alan Kay. Создатель Smalltalk:-D
> потом ругается, что ей Java не нравится из-за тормознутости.К слову почему-то о том, что якобы java де "тормозит" в основном приходится слышать от тех, что серьзно с ней не работал и пользоватся не умеет ...
>> потом ругается, что ей Java не нравится из-за тормознутости.
> К слову почему-то о том, что якобы java де "тормозит" в основном
> приходится слышать от тех, что серьзно с ней не работал и
> пользоватся не умеет ...Java is high performance. By high performance we mean adequate. By adequate we mean slow.
> К слову почему-то о том, что якобы java де "тормозит" в основном
> приходится слышать от тех, что серьзно с ней не работал и
> пользоватся не умеет ...Потому что опытные пользователи жабы уже давно привыкли и смирились.
Для них скорость - уже не главное.
>> К слову почему-то о том, что якобы java де "тормозит" в основном
>> приходится слышать от тех, что серьзно с ней не работал и
>> пользоватся не умеет ...
> Потому что опытные пользователи жабы уже давно привыкли и смирились.
> Для них скорость - уже не главное.Пример:
Отрасль: Телекоммуникации и связь.
Объект: Программные коммутаторы (читай телефонные станции с соот. требованиями к как надежности так и производительности).
Так очень многие их них написаны на Java.
Вот к примеру - продукты компании VocalTec (далеко не лузер) написаны на Java.
> Объект: Программные коммутаторы (читай телефонные станции с соот. требованиями к как надежности так и производительности).
> Так очень многие их них написаны на Java.
> Java
> производительностиОдна из черепашек явно звездит.
> Отрасль: Телекоммуникации и связь.
> Объект: Программные коммутаторыПисать на Java то, что лучше писать на Erlang -- это, безусловно, яркий пример.
>> Отрасль: Телекоммуникации и связь.
>> Объект: Программные коммутаторы
> Писать на Java то, что лучше писать на Erlang -- это, безусловно,
> яркий пример.только один момент, для java чаще всего есть Весь необходимый инструментарий от IDE до множества биндингов а у Erlang'а окрjмя заявленых мегафич нет ничего.
>>> Отрасль: Телекоммуникации и связь.
>>> Объект: Программные коммутаторы
>> Писать на Java то, что лучше писать на Erlang -- это, безусловно,
>> яркий пример.
> только один момент...erlang и создавался для магистральных коммутаторов. Вместо общих слов смотрите хоть иногда, что с чем сравниваете.
> ...erlang и создавался для магистральных коммутаторов. Вместо общих слов смотрите хоть
> иногда, что с чем сравниваете.именно
Вот и подумайте, что лучше -- теплоход со всеми удобствами в пустыне или "корабль пустыни" без штурвала, зато ходкий. :)Из занятного: Армстронг со товарищи одним из первых нашумевших в узких кругах примеров реализовали на таком маршрутизаторе эрланговый httpd, сходу выдавший какие-то дикие количества одновременно поддерживаемых соединений...
При этом Erlang - это виртуальная машина. На одном потоке примерно в два раза медленнее Java.
> На одном потокеЧего именно?
>> На одном потоке
> Чего именно?я правда не хочу объяснять глубины глубин, особенно приведённые аналогии .... вооообще телеком ничем в данном случае не отличается от других направлений в программировании, т.е. параметры выбора платформы :
1. наличие возможности реализовать задуманное (можно сильно развернуть)
2. наличие кадров
3. наличие средств разработки и инструментария
4. возможность поддержки и развития продукта сторонними (не изначальным разработчиком) силами
5. бабкираставте плюсики.
точка.
> я правда не хочу объяснять глубины глубин, особенно приведённые аналогииСпросил к тому, что поток потоку рознь. В том числе важно то, _что_ крутится в глубоких циклах, а также количество этих самых потоков.
> .... вооообще телеком ничем в данном случае не отличается от других направлений
> в программировании, т.е. параметры выбора платформы :Ну да, конечно. Отказ в обслуживании миллиону-другому абонентов совершенно ничем не отличается от GPF отдельно взятой винды, а звонки раскладывать можно и итерируя где-нибудь в байт-коде.
Одни мыслящие подобно запихали J2ME в управляющую систему АЭС, вот только garbage collection никуда не делся -- и чем при инциденте помогло наличие IDE?
> 1. наличие возможности реализовать задуманное (можно сильно развернуть)
> 2. наличие кадров
> 3. наличие средств разработки и инструментарияСм., к примеру, http://ftp.linux.kiev.ua/pub/Linux/xpandrx/highload_2011.pdf (слайд 6).
> 4. возможность поддержки и развития продукта сторонними (не изначальным разработчиком)
> силамиЭто относительно ортогонально в случае сколь-нибудь распространённой технологии (по которой не два спеца на всю планету).
> 5. бабки
Это ортогонально почти совсем.
>> я правда не хочу объяснять глубины глубин, особенно приведённые аналогии
> Спросил к тому, что поток потоку рознь. В том числе важно
> то, _что_ крутится в глубоких циклах, а также количество этих самых
> потоков.
>> .... вооообще телеком ничем в данном случае не отличается от других направлений
>> в программировании, т.е. параметры выбора платформы :
> Ну да, конечно. Отказ в обслуживании миллиону-другому абонентов совершенно ничем не
> отличается от GPF отдельно взятой винды, а звонки раскладывать можно и
> итерируя где-нибудь в байт-коде.Практика -- критерий истины, ну нету ничего для телекома интересного в этой специфичной платформе, телеком и многие другие уже выбрали Java/python/perl и конечно-же це в зависимости от специфики решаемых задач. Те же сип коммутаторы, начиная от asterisk, ser с отпрысками, заканчивая менее известными yate сплошником на сях писаны, и не чего маштабируются в ширь, и да может не так как хотелось-бы но...
Но гугол говорит что на ерланге например ничего путного для вышеупомянотого sip или того-же h323 с собратьями вообще ничего открытого нет, а от попыток реализовать, сквозь смех слезы провываются
> Одни мыслящие подобно запихали J2ME в управляющую систему АЭС, вот только garbage
> collection никуда не делся -- и чем при инциденте помогло наличие
> IDE?Михаил, вы меня таки удивляете, например тем, что технически грамотный человек может сравнивать j2me со стантартной VM, притятутая за уши несчастная АЭС ...
>> 1. наличие возможности реализовать задуманное (можно сильно развернуть)
>> 2. наличие кадров
>> 3. наличие средств разработки и инструментария
> См., к примеру, http://ftp.linux.kiev.ua/pub/Linux/xpandrx/highload_2011.pdf (слайд
> 6).
>> 4. возможность поддержки и развития продукта сторонними (не изначальным разработчиком)
>> силами
> Это относительно ортогонально в случае сколь-нибудь распространённой технологии (по которой
> не два спеца на всю планету).Нет, это крайне важно иметь прямо в зоне непосредственной видимости человека, понимать его плюсы и минусы а не сферического кодера с ЧСВ over9000
>> 5. бабки
> Это ортогонально почти совсем.Бабки - это то что помогает двигаться, это необходимый но чаще сильно ограниченый ресурс. Написать свою ОС тоже можно, но зачем?, если уже есть небходимый и подходящий базис, в данном случае множество библиотек.
Хотелось-бы прамой ответ на слндующий вопрс , вы правда считаете что такая маргинальная платформа как ерланг расматривалась-бы вами в качестве подходящей для постриения программного продукта?
Заз обшибки прошу простить, таблетка плюс кривые руки.
> ну нету ничего для телекома интересного в этой специфичной платформе,
> телеком и многие другие уже выбрали Java/python/perl и конечно-же
> це в зависимости от специфики решаемых задач.Даже не смешно (хотя и жаба, и P/P/P, и тикль, и C/C++ по знакомым телекомам вовсю используются).
> Те же сип коммутаторы, начиная от asterisk, ser с отпрысками, заканчивая менее
> известными yate сплошником на сях писаны, и не чего маштабируются в ширьОсобенно хорошо астериски масштабировались с теми digium'овскими же карточками, которые на PCI устраивали передачу данных bit banging'ом... ладно, это опять про другое, хотя железячники оценят.
> Но гугол говорит что на ерланге например ничего путного для вышеупомянотого sip
Он в чуточку другой нише вообще-то, см. хотя бы #87. :) А конкретно по SIP лучше бы спросить Dear Netch.
>> Одни мыслящие подобно запихали J2ME в управляющую систему АЭС, вот только garbage
>> collection никуда не делся -- и чем при инциденте помогло наличие IDE?
> Михаил, вы меня таки удивляете, например тем, что технически грамотный человек
> может сравнивать j2me со стантартной VMME полегче по части GC, на что и пронадеялись.
> притятутая за уши несчастная АЭС ...
Два ошпаренных радиоактивной водой человека в том случае -- пример последствий выбора платформы по цвету IDE вместо ТТХ на местности.
>>> 4. возможность поддержки и развития продукта сторонними
>>> (не изначальным разработчиком) силами
>> Это относительно ортогонально в случае сколь-нибудь распространённой технологии
> Нет, это крайне важно иметь прямо в зоне непосредственной видимости человека,
> понимать его плюсы и минусы а не сферического кодера с ЧСВ over9000В качестве сторонних сил или изначального разработчика? (не уловил)
> Хотелось-бы прамой ответ на слндующий вопрс , вы правда считаете что такая
> маргинальная платформа как ерланг расматривалась-бы вами в качестве подходящей
> для постриения программного продукта?Здрасьте, мы на ней управляющую ферму "Ломоносова" в МГУ и поднимали. Ссылку на презентацию дал -- гляньте при возможности, там циферки есть.
>> ну нету ничего для телекома интересного в этой специфичной платформе,
>> телеком и многие другие уже выбрали Java/python/perl и конечно-же
>> це в зависимости от специфики решаемых задач.
> Даже не смешно (хотя и жаба, и P/P/P, и тикль, и C/C++
> по знакомым телекомам вовсю используются).Т.е. я правильно понял что в вам лично знакомых телекомах ерлангом успешно пользуются, можно если не секрет спросить в каких именно задачах?
>> Те же сип коммутаторы, начиная от asterisk, ser с отпрысками, заканчивая менее
>> известными yate сплошником на сях писаны, и не чего маштабируются в ширь
> Особенно хорошо астериски масштабировались с теми digium'овскими же карточками, которые
> на PCI устраивали передачу данных bit banging'ом... ладно, это опять про
> другое, хотя железячники оценят.Вот именно, у меня начинает складывается что вы целеноправленно передергиваете, потому как тема была исключительно о программных коммутаторах и использовании в этих целях ерланга
>> Но гугол говорит что на ерланге например ничего путного для вышеупомянотого sip
> Он в чуточку другой нише вообще-то, см. хотя бы #87. :)
> А конкретно по SIP лучше бы спросить Dear Netch.Обязательно поинтерисуютесь, вдруг я хлопок пропустил, заодно быть может вам про биллинг какой или там радиус с дхцп подскажут, это как никак чисто телекомовские атрибуты
>>> Одни мыслящие подобно запихали J2ME в управляющую систему АЭС, вот только garbage
>>> collection никуда не делся -- и чем при инциденте помогло наличие IDE?
>> Михаил, вы меня таки удивляете, например тем, что технически грамотный человек
>> может сравнивать j2me со стантартной VM
> ME полегче по части GC, на что и пронадеялись.Михаил , ваши знания относительно Java а точнее jvm + Java язык в каком-то месте сильно перепутаны, потому как javame это собственно совершенно другая платформа, и упамянать её собственно не имело никакого смысла
>> притятутая за уши несчастная АЭС ...
> Два ошпаренных радиоактивной водой человека в том случае -- пример последствий выбора
> платформы по цвету IDE вместо ТТХ на местности.Про эту грустную историю тоже, ибо выше
>>>> 4. возможность поддержки и развития продукта сторонними
>>>> (не изначальным разработчиком) силами
>>> Это относительно ортогонально в случае сколь-нибудь распространённой технологии
>> Нет, это крайне важно иметь прямо в зоне непосредственной видимости человека,
>> понимать его плюсы и минусы а не сферического кодера с ЧСВ over9000
> В качестве сторонних сил или изначального разработчика? (не уловил)Берём hh.ru как пример, хотя свет клином на нём именно не сошелся, можно и кого другого, и ищем себе под задачу кадры, и не важно начинаем мы только иль необходима поддержка.
>> Хотелось-бы прамой ответ на слндующий вопрс , вы правда считаете что такая
>> маргинальная платформа как ерланг расматривалась-бы вами в качестве подходящей
>> для постриения программного продукта?
> Здрасьте, мы на ней управляющую ферму "Ломоносова" в МГУ и поднимали.
> Ссылку на презентацию дал -- гляньте при возможности, там циферки есть.К большому сожалению не разглядел особенно ничего интересного, что должнобыть правильно ибо больше похоже на маркетиговую листовку, но то что шину сообщений пришлось писать самим - оценил
> Т.е. я правильно понял что в вам лично знакомых телекомах ерлангом успешно
> пользуются, можно если не секрет спросить в каких именно задачах?Сказано же -- эрикссоновские магистральные свичи. Если интересно, гляньте http://www.erlang-factory.com/upload/presentations/416/MikeW... -- там разобрано подробней ;-)
> Вот именно, у меня начинает складывается что вы целеноправленно передергиваете
Просто танки обсуждаете вместе со знакомыми велосипедиками. Уж не знаю, целенаправленно ли, но зрелище печальное.
> потому как тема была исключительно о программных коммутаторах
Перечитайте #25, на которое отвечал. Если что -- астериск в альт собирал ещё в 2003, помнится, и немножко отличаю сегменты telco и SOHO.
> Обязательно поинтерисуютесь, вдруг я хлопок пропустил
</irony>
> заодно быть может вам про биллинг какой или там радиус с дхцп подскажут,
> это как никак чисто телекомовские атрибутыРазве что RADIUS -- биллинги и тем более реализации DHCP встречаются намного шире. Кстати, эрланговый dhcpd, умеющий 10k запросов в секунду, у нас тоже написали -- ISC-шный выдыхался заметно раньше.
> Михаил , ваши знания относительно Java а точнее jvm + Java язык
> в каком-то месте сильно перепутаны, потому как javame это собственно совершенно
> другая платформа, и упамянать её собственно не имело никакого смыслаУпомянул как факт неадекватного выбора технологии (причём SE/EE были бы _ещё_ более неадекватными задаче). Неужели настолько непонятно?
> Берём hh.ru как пример, хотя свет клином на нём именно не сошелся,
> можно и кого другого, и ищем себе под задачу кадры, и
> не важно начинаем мы только иль необходима поддержка.Брр. Мы сами вырастили нужное количество на проект, например. Вы же не думаете, что программистов на hh с завода привозят? :)
> К большому сожалению не разглядел особенно ничего интересного, что должнобыть
> правильно ибо больше похоже на маркетиговую листовкуМожно посмотреть Ваши слайды к докладу, принятому на любую техническую конференцию сравнимого уровня? (извините, если вышло "сперва добей" -- но взялись судить, предъявите квалификацию)
> но то что шину сообщений пришлось писать самим - оценил
Погоняйте 400Mbps со сложной структурой на имеющихся, тогда эти слова будут хоть чего-то стоить.
Н-да, опять офтопик развели. Закругляюсь.
>Упомянул как факт неадекватного выбора технологии (причём SE/EE были бы _ещё_ более неадекватными задаче). Неужели настолько непонятно?Каким бы хорошим не выглядел Erlang, но от сборщика мусора его не освобождали. Неожиданные сборки также возможны.
И кстати вот: http://shootout.alioth.debian.org/u64q/benchmark.php?test=al...В производительности Erlang ЗАМЕТНО сливает, а по памяти примерно 50/50.
Erlang с успехом можно использовать во многих предметных областях.
Сама платформа уже сейчас позволяет очень многое, но девелоперская инфраструктура на текущий момент оставляет желать лучшего.
> К слову почему-то о том, что якобы java не "тормозит" в основном приходится слышать от тех, что серьзно с ней не работал и пользоватся не умеет ...Исправлено.
Что вы подразумеваете под "работал". Лично мне программировать не приходится (админ), но достаточно много приходится пользоваться Жаба-программами (что особо отмечу - фирменными) и результат весьма не в пользу Java.
Вы достоинства Java обсуждаете с точки зрения разработчиков: дескать, легко учить, управление памятью и т. п. А вот пользователей забываете: нужно ставить jvm которая жрет ресурсы как не в себя; GUI зачастую отличается от системного, а значит программа выглядит "не родной" и т. п. Хороший программист напишет хорошую программу хоть на java, хоть на c++, плохой программист наделает кучу багов и там, где jvm ему будет всячески помогать, автоматизировать все что можно и думать за него. Так что дело в руках и в голове, а не в языке.> а людей, знающих СИ от и до, в мире всего несколько человек
Посмеялся, спасибо. А вы с англичанами будете общаться только когда выучите английский язык от и до? Нормальные люди используют ровно то, что им нужно, а не все, что дает им (в данном случае) язык программирования. А вы продолжайте учить свою Java "от и до".
>GUI зачастую отличается от системногоSWT же!
> а людей, знающих СИ от и до, в мире всего несколько человек.а зачем знать "от и до"? если речь идёт о plain C, достаточно прочитать k&r ;)
>Чем Вам Java не угодила, замечательный и простой язык, который легко выучить
>меня знакомая — аспирант кафедры системного программирования — пишет в цикле:
>String s = new String();
>s = "data # " + arg[0] + " " + arg[1];
>потом ругается, что ей Java не нравится из-за тормознутости.Поделил на ноль?
К слову о простоте. Ява - это сложный язык с огромной платформой обвешанной энтерпрайзными технологиями, поэтому осилить писать на ней эффективные программы дано не каждому, за-то тормозные поделки писать могут все. Лично я счастлив, что занимаюсь встраиваемым ПО и осиливать многокилометровые талмуды не приходится.
Насчёт тормозов, вот использую я hudson для сборки сишных проектов, и никак не могу понять почему он жрет более 500 мегабайт памяти и 100% грузит проц. А ведь главное нихрена полезного при этом не делает. И это пример хорошего функционального ПО.
>А ведь главное нихрена полезного при этом не делает.Делает, почитайте документацию и будет Вам озарение.
> Насчёт тормозов, вот использую я hudson для сборки сишных проектов, и никак
> не могу понять почему он жрет более 500 мегабайт памяти и
> 100% грузит проц. А ведь главное нихрена полезного при этом не
> делает. И это пример хорошего функционального ПО.На 100% с вами согласен, НО !!! Здесь вы обязаны привести пример одинаковых по функционалу приложений, но одно на Java, а другое нет. Вот тогда и можно проводить сравнение.
Так получается, что вы Hudson с утилитой make сравниваете и ругаетесь на тормознутость Hudson-а.
Hudson вероятно правильно сравнивать с аналогом CruiseControl-ом. Та что ж это делается CruiseControl тоже написан на Java. Люди проснитесь, вселенский заговор, не иначе.
>Здесь вы обязаны привести пример одинаковых по функционалу приложений, но одно на Java, а другое нет. Вот тогда и можно проводить сравнение.Если бы мне понравились другие CI системы на других языках, я бы с hudson не связался.
>Так получается, что вы Hudson с утилитой make сравниваете и ругаетесь на тормознутость Hudson-а.
Как их можно вообще сравнивать, это разные вещи. Более того, в моём случае hudson вызывает gmake для сборки проекта, при этом во время сборки в top'е ни gmake, ни GCC даже не появляются, а java и hudson занимает первые строчки. А ведь всё что он делает в данном случае - это ждёт завершения утилиты gmake, мигает иконкой и пишет логи, ну и конечно же жрёт память и процессор.
Не так. Ява - простой (даже примитивный) язык. И за свою примитивность она расплачивается сложностью библиотек и простынями кода - потому что сложность задач никуда не делась и надо с ней какими-то средствами работать.
> Не так. Ява - простой (даже примитивный) язык. И за свою примитивность она расплачивается сложностью библиотек и простынями кода - потому что сложность задач никуда не делась и надо с ней какими-то средствами работать.История далеко не новая. Еще лет двадцать назад с ней столкнулись те, кто писал на языке Bourne shell. Чтобы посмотреть на последствия, далеко ходить не нужно - достаточно взять практически любой административный скрипт, решающий более-менее сложную задачу. Вместо одной-двух красивых и прозрачных строчек, мы увидим там простыню на 200Кб, которую можно даже не обфусцировать - она и так запутана по самые не балуйся.
Проблема в том, что этим недософтом приходится работать. И глюки и тормоза не зависят от "авторства": и цисковские управлялки "железками" тормозят не меньше, чем кривописанные студентами программы.
И насчёт переносимости тоже далеко не всё гладко: начиная с того, что разные реализации Жабы под разные ОСы работают "чуточку по разному". Отсюда и "эффекты".
Ну и пик идиотизма пеЙсателей: писать Жаба программу только (!) для венды на Жабе!
Кстати, особо "весело" работать с такого рода Жабоидами в виртуалках: при условии, что остальное всё работает нормально, но Жаба-проги имеют тенденцию "подвешивать" гостевую. Вот это гуано, например: BMC Remedy OnDemand
> Хоть с конца текст новости читай. Обидно...А если по сути постараться разобраться ?
Та же Cassandra - прекрастная NoSQL БД, написанная на Java ... и вкустностей вагон, и стабильно, и все работает.
И таких примеров можно привести очень много ....
А потому нет необходимости исходить слюной при упоминании слова java (который к слову - великолепный язык),а разбиратся в сути.
А суть должна быть такой: Если это работает так, как завлено, то мне лично плевать на чем она написана.
> Та же Cassandra - прекрастная NoSQL БД, написанная на Java ... и
> вкустностей вагон, и стабильно, и все работает.Только очень мееееедленно. И жрет дофига. А так, конечно, работает. Когда не падает.
>> Та же Cassandra - прекрастная NoSQL БД, написанная на Java ... и
>> вкустностей вагон, и стабильно, и все работает.
> Только очень мееееедленно. И жрет дофига. А так, конечно, работает. Когда не
> падает.Вы это Twitter'у расскажите. А то мужики то не знали ...
> Вы это Twitter'у расскажите. А то мужики то не знали ...Twitter уже привык закупать в 3 раза больше серверов чем нужно. В реальеом мире этого делать никто не будет и cassandra нигде не используется.
>Twitter уже привык закупать в 3 раза больше серверов чем нужно. В реальеом мире этого делать никто не будет и cassandra нигде не используется.А твиттер в курсе что они в три раза больше серверов купили чем им нужно? Это что использование Java позволяет в три раза уменьшает необходимое количество серверов или Cassandra?
Не всё так в Java однозначно(в остальных платформах/языках, увы, тоже).Вот, например, целочисленное суммирование элементов массива в цикле, типа:
__int32 sum = 0;
for (int i = 0, n = vec.size(); i < n; i++)
sum += vec[i];Чтобы на GCC результаты приблизились к Java нужно пошаманить. g++ -O3 -funroll-loops помогает. При этом Java будет компилить код, который оптимален для данного процессора, а GCC неплохо оптимизирует для -march. Только с данным ключом на другом процессоре будет тормозить или вообще работать не будет.
Память в Java жрут коллекции. Если это неприемлемо, то используют массивы. Может это кому-то покажется не совсем в стиле Java и не очень удобным, но по сравнению с C/C++ вполне приемлемо.
В итоге, (при грамотном подходе, разумеется) производительность систем, где активно используются данные из памяти, ВСЕГДА упирается в пропускную способность памяти, а не в язык разработки. Оптимизировать можно, только с помощью уменьшения объёма данных, для более эффективного использования кэша.
P.S.
За конкретный пример спасибо Роману Елизарову http://elizarov.livejournal.com/ ;-)
Кстати это человек, который РЕАЛЬНО делает высоконагруженные производительные системы.
> P.S.
> За конкретный пример спасибо Роману Елизарову http://elizarov.livejournal.com/ ;-)
> Кстати это человек, который РЕАЛЬНО делает высоконагруженные производительные системы.... и за многие годы работы с ними, как любой разработчик на его месте, видел миллионы случаев, когда жаба сливает сям. Но он также случайно обнаружил редкую, уникальную ситуацию, когда жаба почти не сливает, и не замедлил привести ее в качестве практического примера =)
>... и за многие годы работы с ними, как любой разработчик на его месте, видел миллионы случаев, когда жаба сливает сям.Если бы он видел миллионы случаев слива, то не работал бы с Java.
Посмотрите клиентов для интереса: http://www.devexperts.com/ru/clients.html
ММВБ, РТС о чём-нибудь говорят? Плюс ведущие брокеры. Это всё реальный хардкор для приложений. Миллионы транзакций.Кстати он говорит, что C должен знать любой программист.
> Но он также случайно обнаружил редкую, уникальную ситуацию, когда жаба почти не сливает, и не замедлил привести ее в качестве практического примера =)
Это просто самый прямолобый пример, который не завязан на всякие специфичные вещи и его можно адекватно воспроизвести во многих языках/платформах.
Почему-то тоже именно это подумал...
Ну да, ну да... Если всё то же самое написать на си, то конечно можно сэкономить примерно 18 мегабайт памяти и после жёсткой-жёсткой компиляции для совсем конкретного процессора оно на этом процессоре возможно будет быстрее на 1-2 процента.
Итого 1) экономия 18м памяти (а мы ведь говорим о высоконагруженных кластерах, где вся доступная многогиговая память будет занята нашим приложением)
2) Многотрах админов с компиляцией и бубном ради 1-2 процентов (а ведь джаву просто запустить и всё :)
3) Нужно потратить лишний миллион человеко-часов на разработку, хотя эти ресурсы можно потрать на что - либо гораздо более полезное и нужное.Но вам - то на вашей кухне чо, оналитеги хреновы
Он будет не меньше по размеру (это как раз фиолетово) а быстрее. Именно это требуется для постоянной синхронизации объектов. Там любая прибавка скорости критична... а тут в качестве языка - жаба...
> Он будет не меньше по размеру (это как раз фиолетово) а быстрее.Вот здесь и есть ошибка!
Скорость работы алгоритма зависит исключительно от используемой им памяти. Всё.
Чем меньше памяти использует алгоритм, тем быстрее он выполняется на современном железе.Как только данные перестают помещаться в кэш происходит жуткая просадка. В Java даже есть ключ UseNUMA (на Windows не работает), который эффективно (с помощью данных об архитектуре памяти от ОС) по ядрам распределяет потоки, чтобы повысить вероятность нахождения в кэше полезных данных.
Т.о. память тормозит, а процессор простаивает, даже если он выполняет Java, которая в три раза тупее C(по мнению некоторых). Процессор с лёгкостью успевает перемолоть даже Java. Память за ним не поспевает. И в данный момент НЕВОЗМОЖНО чего-либо сделать. На производительность контроллера памяти и самой памяти невозможно повлиять переписыванием программы на другой язык.
Т.е. Может быть небольшой блок данных и весьма сложный алгоритм обработки. Особенно - математические расчёты.
> Ну да, ну да... Если всё то же самое написать на си, то конечно можно сэкономить примерно 18 мегабайт памяти и после жёсткой-жёсткой компиляции для совсем конкретного процессора оно на этом процессоре возможно будет быстрее на 1-2 процента.Приведенные вами цифры характерны не для жабы, а для нормального компилируемого языка.
Для типичного перехода "жаба -> си" - потребление памяти уменьшится примерно в 18 раз, и работать будет быстрее на 100-200%.
Не лопниш, деточка?
> Ну да, ну да... Если всё то же самое написать на си,
> то конечно можно сэкономить примерно 18 мегабайт памяти и после жёсткой-жёсткой
> компиляции для совсем конкретного процессора оно на этом процессоре возможно будет
> быстрее на 1-2 процента.После перехода с Java на C, экономия ресурсов и прирост скорости обычно составляют не единицы процентов, а разы. Десятки и сотни раз.
> После перехода с Java на C, экономия ресурсов и прирост скорости обычно
> составляют не единицы процентов, а разы. Десятки и сотни раз.Будте так любезны, подтвердите свои утверждения фактами.
Потому, что на сегодняшний день имеются совсем иные цифры, из которых следует, что Java вполне сопоставима с C++ по производительности в режиме компиляции -O2.
> Будте так любезны, подтвердите свои утверждения фактами.Запросто.
Была у нас система биллинга. Переписали основную часть (не фронтенд, он изначально на пыхе был) с жабы на си - перестало тормозить. И не тормозит даже после того, как перенесли с выделенного мощного сервака на слабый, с кучей других задач.
Вот такие пироги.> Потому, что на сегодняшний день имеются совсем иные цифры, из которых следует,
> что Java вполне сопоставима с C++ по производительности в режиме компиляции
> -O2.Фороникс небось?
>> Будте так любезны, подтвердите свои утверждения фактами.
> Запросто.
> Была у нас система биллинга. Переписали основную часть (не фронтенд, он изначально
> на пыхе был) с жабы на си - перестало тормозить."перестало тормозить" это увы, но мало информации.
Тут надо сравнивать:
а) код
б) потребленное процессорное время и памяти.дело в том, что при переписывании ведь не просто так один в один.
Возможно в старой реализации было что-то. что достаточно было переписать в Java.> И
> не тормозит даже после того, как перенесли с выделенного мощного сервака
> на слабый, с кучей других задач.
> Вот такие пироги.
>> Потому, что на сегодняшний день имеются совсем иные цифры, из которых следует,
>> что Java вполне сопоставима с C++ по производительности в режиме компиляции
>> -O2.
> Фороникс небось?Неа.
Источники различные.
начиная о себя, заканчивая тем. что в инете опубликовано ... на большинстве задач разброс не более 20 %.
Успокойтесь)) Сейчас в вопрос часто ставят node.js vs Java. А на декстопе в простеньких приложениях Java не прижилась в первую очередь из-за выпиливания ее из винды в далеких годах, необходимости установки виртуальной машины. Всякие сложные декстоп приложения типа Maple/Ramus/и т.п.-и на десктопе отлично себе живут.
>Была у нас система биллинга. Переписали основную часть (не фронтенд, он изначально на пыхе был) с жабы на си - перестало тормозить.И какой сервер приложений был ??
Сколько раз наблюдал просадку БД. Даже на PHP.
Так здесь переписыванием клиента мало поможешь.
Но, чтобы БД не тормозила, а само приложение тормозило - это первый раз слышу.Недавно документооборот на Java тестировали. Т.к. специфику приложения знали плохо, то под БД и сервер приложений взяли одинаковые сервера. Ксеоны с 16ядрами. Просела PostgreSQL.
И как здесь переписывание на C поможет? Переписывание SQL-запросов может помочь, но никак не переписывание серверного приложения.
>Фороникс небось?HotSpot JIT на текущий момент один из лучших компиляторов для x86 и SPARC. Это признано многими экспертами в данной области. И! Вы сами это можете проверить!
Другое дело, что Java не на один JIT завязана.
> После перехода с Java на C, экономия ресурсов и прирост скорости обычно
> составляют не единицы процентов, а разы. Десятки и сотни раз.Ржунемагу!!
Про десятки и сотни жесть!Я понимаю, если бы вы с PHP сравнили.
> Ну да, ну да... Если всё то же самое написать на си,
> то конечно можно сэкономить примерно 18 мегабайт памяти...на каждый байт хранилища...
> и после жёсткой-жёсткой компиляции для совсем конкретного процессора оно на этом процессоре возможно будет быстрее на 1-2 процента
...чем java на десятке таких процессоров...
примеров кода, я так понимаю, не будет ;)...
судя по камментам, новость была о новой версии джавы, а не о распределённой памяти %)
> Код компонентов Galaxy написан на языке Java.Непонятно, почему не на питоне? Все-таки, java - это вчерашний день промышленных приложений. Питон может тормозить и жрать память в разы эффективнее.
Потому что в питоне не обязательно создавать новый класс для каждого чиха. Как известно, ёмкость и понятность кода для промышленных приложений являются большим минусом.
Что вам еще известно, что Дед Мороз/Б-г существует?
> Потому что в питоне не обязательно создавать новый класс для каждого чиха.
> Как известно, ёмкость и понятность кода для промышленных приложений являются большим
> минусом.Это легко лечится созданием специализированного фреймворка.
Опять же, созданные дополнительной прослойкой тормоза и жрач памяти не помешают.
Я вот не пойму одну вещь. Обычно в пользу простыней, длинных названий и т.п. приводятся аргументы что, мол, так поддерживать удобнее. Один я такое читаю с трудом? Вот есть какая-нибудь идиома-заклинание из перла, сей и тому подобного. Один раз в этом разобраться надо. Но идиом этих довольно мало, зато потом однив взглядом видишь, что происходит. А теперь берём джаву или код на плюсах (там тоже можно в джава-стиле писать) - простыня с кучей похоже названных переменных и методов. Глаз замыливается моментально, пять строк прочел - в первой уже путаешься. Как это может быть более лёгким в поддержке?
Да, ты такой один.
Ложь.
Как говорится, "представляет чисто академический интерес". Видимо, поэтому и открыли.