Oracle анонсирует бесплатную и Premium версии Java VM

> Вы проспали всё. Уже нет, а дальше - больше. Дело в том, что стоимость электроэнергии становится очень весомым фактором...

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

>> Ну а как именно я это делаю - знать Вам не обязательно. :-) Я не опен соурс пишу.

«У нас есть такие приборы! Но мы вам о них не расскажем» (с)

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

А показывать вам закрытый код и нарушать контракты я не буду. :) Прямо детский сад какой-то. Скоро и ключи от квартиры запросят.

>>И хотя в теории, программа на машинных кодах может быть быстрее

Я люблю это выражение «в теории». Ассемблер для 86-х кончился, когда за короткий срок прошла волна различных, с точки зрения оптимизации, процессоров.

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

Вот и я о том.

А если хочется на ассемблере программировать... Бог мой! Сколько же случаев, когда ассемблер уместен... Взять тот же GA144. Под него пока нет компиляторов, и наверно, не будет в классическом смысле этого слова. Там все 144 ядра — твои.

Конечно. Но тогда не лучше ли написать DSL на высокоуровневом языке вроде Haskell и писать без геммороя?

> очень познавательно. люблю беллетристику.

А я люблю плюсатую шизофазию. Очень забавляет, как народ с раздудым ЧСВ пучится, решая даже элементарные задачи через зад, и не может прийти к решению даже за неделю. А если и приходит, то решение это сливает по всем статьям аналогичному решению на Haskell.

Пока что рекорд такой:

Haskell: ~50 строк C++: ~1000 строк

Haskell: задача решена С++: задача решена частично (около 50% требований реализовано)

Haskell: программа очевидна С++: в программе путается даже автор

Haskell: написано за 2 часа С++: неделя

Ну когда же оно загнется?

>Но тогда не лучше ли написать DSL на высокоуровневом языке вроде Haskell и писать без геммороя?

Наверно что-то подобное и будет. Скорее всего какое-то средство моделирования, которое будет пытаться раскладывать алгоритм по различным ядрам. Но компилятором в классическом смысле этого слова оно не будет.

Очень хотелось бы, чтобы данная разработка пережила фазу стартапа. Но пока остается только надеяться.

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

Я и не выпендриваюсь. Код у меня не тормозит - то, что должно работать быстро, я пишу на Си, остальное - на Питоне. Но, когда я слышу о софте с микросекундными временами отклика на Яве, а потом о таком же софте на Хаскеле, мне так и хочется поерничать.

А показывать вам закрытый код и нарушать контракты я не буду. :)

Этого никто и не ждет.

Что за задача-то? Хорош уже сферическими конями кидаться, давай конкретику. А то ты смахиваешь на школоло с завышенным ЧСВ и ФГМ

Я тебе самому разжую. Не умеешь использовать C++ - не берись судить. Если C++ программа быстрее, чем ассемблерная, значит автор не осилил алгоритм. Мне приходилось делать ассемблерные вставки в критических местах, потому что человеку легче догадаться, как используются переменные и cache процессора, чем компилятору. Обычно выигрыш - 25-30%. А уж про Java - это вообще бред сивой кобылы. Разница, к примеру, между Tomcat (60..100 tran/sec) и Apache (2000..2500 tran/sec) хорошо просматривается.

> Но основная проблема в том, что Oracle ограничивает сферу применения.

К примеру запускать на мобильных полученную программу ты не имеешь права.

можно тынц на то, что Oraclt ограничивает сферу применения OpenJDK? запрещает перенос на новые архитектуры и т.п.?

>приходилось делать ассемблерные вставки в критических местах

Когда же вы все передохните!

>не знаю какой Вы эколог, но маркетолог Вы точно плохой :) если бы так было как Вы говорите - никто бы не использовал

Вы взяли выдрали фразу из контекста и убрали важное слово «масштаб». Таки вы отличный пиараст. Атомная энергия требует выгодна только при использовании в глобальных масштабах, два села и ферму вы ей, простите, не отопите. Особо в этом плане умиляют автомобили из Fallout 3 с атомными реакторами на борту...

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

стоит посмотреть на астериск к примеру ;)

Ты сам-то понял, что написал? Теперь понятно, почему у тебя Java и Haskell оказываются быстрее. Ты сравниваешь фичу языка, написанную приличными людьми, создавшими Haskell, с реализацией того же самого, только написанным недопрограммером вроде тебя. C++ надо знать, тогда от него будет отдача.

Tomcat (60..100 tran/sec)

Это где такое? Как вы это написали? Где Thread.sleep()?

иммутабельных строк?

Ты о StringBuilder?

> Ты сам-то понял, что написал? Теперь понятно, почему у тебя Java и Haskell оказываются быстрее. Ты сравниваешь фичу языка, написанную приличными людьми, создавшими Haskell, с реализацией того же самого, только написанным недопрограммером вроде тебя. C++ надо знать, тогда от него будет отдача.

Тот же вопрос к тебе.

Сначала потрудись объяснить, как это проблемы программы на С++, написанные «экспертом» и красота программы на Haskell, написанной мной приводят тебя к мнению о том, что я, оказывается, недопрограммер?

Может это намек, что для того, чтобы писать такое суровое говнище, мне нужно еще более углубиться в плюсы? Спасибо, я уже лет 8 в них плавал, не интересно более.

И какую конкретно фичу ты имеешь в виду?

В общем, проспись, алкашик.

Вы взяли выдрали фразу из контекста и убрали важное слово «масштаб».

тогда учитесь так строить предложения чтобы Вас понимали правильно :)

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

> Я тебе самому разжую. Не умеешь использовать C++ - не берись судить.

Жевать тебе нечем, беззубое.

Если C++ программа быстрее, чем ассемблерная, значит автор не осилил алгоритм.

Да ну? Почему же она обычно быстрее, даже если алгоритм такой же самый? Вообще идентичный.

Мне приходилось делать ассемблерные вставки в критических местах, потому что человеку легче догадаться, как используются переменные и cache процессора, чем компилятору. Обычно выигрыш - 25-30%.

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

И выигрыш при правильном использовании кешей часто более 50%.

А уж про Java - это вообще бред сивой кобылы. Разница, к примеру, между Tomcat (60..100 tran/sec) и Apache (2000..2500 tran/sec) хорошо просматривается.

Проспись а потом пиши такие высеры. Какие-то транзакции с непонятными настройками для хер знает какого софта. Твои среднепотолочные цифры интересны только тебе.

Разница, к примеру, между Tomcat (60..100 tran/sec) и Apache (2000..2500 tran/sec) хорошо просматривается.

Чувак, выдыхай. Какие на..й транзакции в веб-сервере?

Настоящие мужики отправляют SQL в POST запросах по HTTP, нечего тонкий клиент, тонкий клиент...

Тут видимо товарищ как-раз из таких, суровых. Которыее sql на стороне клиента жабоскриптом собирают.

Сцылку скинь, я уже DROP TABLE приготовил

>>Я что-то не замечал, чтобы от С++ программ было болше проблем чем от Java программ.

А вы их запускать пробовали?

Педросянский юмор как доказательство.
Ай да молодец!

Котроль качества, говорите? :-) Даже не смешно.

Это потому что вы его не видели.
Трэйдерские программы работают исключительно на С/С++ и даже РАЗГОВОРОВ о применении Java/.Net там нету.
Неспешная аналитика и прочее - да, там даже перл бывает.

Я писал программы на Java с откликом в микросекундах.

Дитя, я писал о НЕСКОЛЬКИХ трэйдерских серверах. Синхронизированных.
Со специально оттюным ядром Линукса.
А вы о «Привет Мир!»

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

:)
Расскажите мне пожалуйста как задействовать SSE или NEON из Java прежде чем рассказывать сказки и потом, почему С++ это умеет а Java нет.

Если инструментария не хватает - используй native library.

Overhead в Java при вызове Native кода обычно больше чем выиграх от его использования.

В моно, кстати такого нет.

>Ну а как именно я это делаю - знать Вам не обязательно. :-) Я не опен соурс пишу.
А это достойно умиления.
У меня младший сын тоже так иногда любит говорить.
Вам, случайно не 9 лет? Уж очень у вас способ ведения спора с ним схож.

>А показывать вам закрытый код и нарушать контракты я не буду.
Слеза навернулась на глаза, так захотелось зевнуть от этих несовершеннолетних сказок.

Ну хоть скажите где работает такое приложение на Java

С++ серверы o которых я говорил работает в Meril Lynch, RBC Capital Markets и нескольких мелких трэйдинговых конторах.

>Если C++ программа быстрее, чем ассемблерная, значит автор не осилил алгоритм.
Для Итаника или Риск писать на ассемблере практически невозможно.

>можно тынц на то, что Oraclt ограничивает сферу применения OpenJDK?
http://www.google.ca/search?q=ASF+TCK+problem&ie=utf-8&oe=utf-8&aq=t&rls=org....

запрещает перенос на новые архитектуры и т.п.?

Я о таком не слышал и не писал.

>Я что-то не замечал, чтобы от С++ программ было болше проблем чем от Java программ.
Да, давайте сравним его с аналогичным на Java
У меня даже установка есть - ARM/512mb/1Ghz - ShivaPlug называется.

Продолжая мысль, поэтому драйверов там практически нет.
Ассемблер спарка понятнее чем х86 в 100 раз.

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

>ShivaPlug называется.

Как приобретал? Или ты не на территории РФ?

Я в Канаде живу.

Внутренний проект за семью проксями. Используется в крупном банке. Так что к сожалению drop table прийдется разготавливать ;)

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

Вы так хотите жить среди ядерных могильников и гробиков закрытых АЭС? Ведь вы же ещё не забывайте, что АЭС и после закрытия требует эксплуатационных затрат (поскольку «чадят» ещё долгое время после консервации).
Собственно, в этом плане по-моему использование метатенков и рапсового спирта как-то более экологично, а главное - в перспективе результаты предсказуемы хотя бы.
А вообще всё это тема для долгого разговора, потому что на самом деле использование альтернативных источников где-то возможно и оправдано на 100%, а где-то наоборот - не только не даёт экономического эффекта, но и влечёт за собой тяжёлые экологические последствия. Такая ситуация складывается, например, в Москве, где мусор пытаются пустить на вторичную переработку по политическим мотивам с целью отмыва бюджетных средств, при этом в итоге это приводит к огромному ничем не оправданному экономическому и экологическому ущербу в результате разрастания полигонов захоронения ТБО, а что самое страшное - к процветанию криминального бизнеса, крышующего нелегальные свалки. И если полигоны - это просто деньги, выброшенные на ветер, то свалки - это ещё и микрозоны экологического бедствия, по сравнению с которыми зона отчуждения - это кристально чистый рай земной.

Вы так хотите жить среди ядерных могильников и гробиков закрытых АЭС? Ведь вы же ещё не забывайте, что АЭС и после закрытия требует эксплуатационных затрат (поскольку «чадят» ещё долгое время после консервации).

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

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

>Вы так хотите жить среди ядерных могильников и гробиков закрытых АЭС?

Ну-ну. Есть очень интересные решения. Стоит себе небольшой реактор, необслуживаемый и с «регулятором» на основе расплава изотопа лития, и с минимумом контрольной аппаратуры. Плюс теплообменник и турбина.

Как только реактор отслужил свое, он целиком увозится на переработку, а в случае необходимости и теплообменник (потому что он слегка грязным будет). Самое страшное, что может случиться — реактор рванет а-ля Чернобыль. Но на это есть проектировщики и в их силах сделать так чтобы этого не случилось никогда. Второе, что может случться, это разрыв первого контура (рекатор-теплообменник): относительно «грязный» теплоноситель загрязнит территорию станции. Но, поскольку теплоноситель там натрий, сильно фатальных проблем не будет. А реактору на это практически пофиг, он саморегулирующийся. Еще может сломаться теплообменник, и тогда из строя выдет турбина, опять же возможно с загрящнением территории станции.

>>>> Сам JIT - тоже оверхед.

зато очень хорошиий вкусный оверхед.

> Overhead в Java при вызове Native кода обычно больше чем выиграх от его использования

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

что твой нейтив код делает? return и все? естественно, что оверхед будет куда больше. если ты неспособен решить что выносить в нейтив, а что не следует, то угадай из 3 раз в чем проблема.

>простите, я чего-то Вас в гриме не признал, Вы специалист по энергетическим реакторам с ядерной установкой или по утилизации отходов ядерного производства?

Скорее второе, хотя реально у нас лекций толковых на эту тему не было. Всё больше про утилизацию покрышек и авомобильных аккумуляторов рассказывали, про дробилки, центрифуги, грохоты, установки для очистки воздуха... Это же городская экология всё-таки. Ситуацию с ядерной энергетикой обрисовывали достаточно общо, и то на собственно экологии, «побочном предмете» (мы же инженеры минус экологи :) ).
Так что признаюсь, глубоко ситуацию с ядерными реакторами не знаю, знаю только,что утилизация их отходов, а главное - период после консервации - это большая проблема. Но, собственно, об этом и по результатам поиска в гугле почитать можно, «общий привет».
Ситуацию с полигонами знаю лучше, даже диплом писал по теме дегазации полигона в Лоо (Сочи).
Прогноз же я написал в самом начале: энергия будет дорожать год от года всё ощутимее, поэтому у технологий виртуализации - большое будущее. На в Москве ещё и аренда помещений и стоек в дата-центрах дешеветь точно не будет. А виртуализация предполагает всё-таки оптимизацию расхода ресурсов как минимум, что в общем заставляет задумываться об экономической целесообразности Java-монстров.

>угадай из 3 раз в чем проблема.
Проблева в наличии оверхеда.
В моно его нет.

Кстати, WepCrack GUI написан на Mono - +1 для Mono однозначно. Интерфейс странный, но работает быстро, запускается тоже, память не кушает и таки ломает ключи!

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

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

Так что признаюсь, глубоко ситуацию с ядерными реакторами не знаю, знаю только,что утилизация их отходов

ну, тогда для начала рекомендую посмотреть чем отличаются: «ядерные отходы», «ядерные материалы», «радиоактивные отходы», «отработанное ядерное топливо» и т.д.

это важно, коль скоро мы хотим говорить об этой проблеме

на самом деле, к примеру, отработанное ядерное топливо спокойно перерабатывается и вновь пускается в дело, а проблему представляют именно детали реактора, типа отработавших ТВЭЛ'ов и прочая, но не забываем - технология не стоит на месте

и да, экологический ущерб от работы АЭС на порядки меньше чем от тех же ТЭЦ

>> ну и славненько: смерть поделия не за горами )

Угу и линупс не нужен будет, свалю на .NET

Скатертью дорога! Нах такие горе программисты.

>экологический ущерб от работы АЭС на порядки меньше Редко, зато метко. Превед из Чернобыля.

барыги

> С++ серверы o которых я говорил работает в Meril Lynch, RBC Capital Markets и нескольких мелких трэйдинговых конторах.

Ну расскажи, взрослый ты наш, что и как делают эти сервера. И главное, чем их существование доказывает нереальное превосходство плюсов. Кроме, конечно, непрофессионализма разработчиков, выбравших низкоуровневый язык, на котором даже такое говно компилируется (причем даже без warning'ов с -Wall) и запускается:

#include <string>

#include <iostream>

int foo(const std::string &x) {

   return x==«bar»;

}

int main(int argc, char **argv) {

   std::cout << foo(false) << std::endl;

}

> я писал о НЕСКОЛЬКИХ трэйдерских серверах. Синхронизированных. Со специально оттюным ядром Линукса. А вы о «Привет Мир!»

Ванга, перелогиньтесь.

Синхронизованны ли сервера и сколько их никак не влияет на принятие и обработку данных с них. Вот если слать надо на несколько серверов, тогда может и влияет. Но зависит от протокола. Но Вашему Вангству этого, похоже, не понять. Зато пафоса...