Как технарю из России стать программером в США за 150К

[Brazen]

Ну и вы все еще не ответили на вопрос, какой дополнительной инфой обладает С++ компилятор, и которая не известна джаве?

Как минимум :
1. Все неиспользуемые модули, поля, классы и т.п.
2. Inline функции, процедуры и т.п.

В джаве хотспот тоже не компилирует неиспользуемые поля и классы. Что там дальше?
Про инлайн я вообще не понял? Я тоже знаю такое слово..

Я тоже не понял. Все это стандартные фичи компилятора. Инлайнит сам, если видит, что так быстрее.

[nightmare2]

Ладно, господа. Вам задали написать систему управления ядерной станции. Или аэродромного локатора и диспетчерской службы. Или систему наведения антенн спутника. На чем будете писать?

Вполне можно написать на миксе, ЮИ и всякую бухгалтерию на джаве а то что поближе к железу на С, а вы это к чему спрашиваете?

+1

[zzhou]

Hibernate - это внешняя библиотека. И в ней таки есть баги. JSF - тягучий кусок дерьма. Могли бы что-нибудь поприличнее вспомнить, хотя бы простецкий JSP или компонентный Wicket, но не JSF. Спасибо, этого не надо.

БД на жабе - это низкоуровневые вещи типа послать запрос, получить таблицу. Или вместо таблицы получить исключение, которое потом через десять этажей надо прокидывать. Минимальный уровень, на котором работа с БД на жабе становится приятной - это iBatis. Таки библиотека. Неродная.

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

Ладно, господа. Вам задали написать систему управления ядерной станции. Или аэродромного локатора и диспетчерской службы. Или систему наведения антенн спутника. На чем будете писать?

NASA марсоходом на Яве управляет. Ничего они в технологиях не понимают!

[Zombie416]

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

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

Элементарный (пусть и надуманный) пример. Ваша программа требует нечто от системы пользователя, например зовет функцию get_x() 500 тыщ раз, и функция эта "дорогая", с user mode->kernel mode и т.д. На некоторых системах возвращенное значение будет константой, на других - нет. Так что кешировать возвращенное значение внутри вы не можете.

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

[Brazen]

Ладно, господа. Вам задали написать систему управления ядерной станции. Или аэродромного локатора и диспетчерской службы. Или систему наведения антенн спутника. На чем будете писать?

Вполне можно написать на миксе, ЮИ и всякую бухгалтерию на джаве а то что поближе к железу на С, а вы это к чему спрашиваете?

Да так, обстановку разрядить Но я бы не стал писать даже UI для ядерной станции на джаве.

[Brazen]

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

То есть вы не спорите с тем, что это внешняя библиотека, к тому же еще и от стороннего разработчика?

[crypto5]

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

С чего это они не могут разбивать кучу на области для потоков?

Можно пруфлинк про такой менеджер памяти?

Могут, того в C++ это не поможет,т.к. один поток может захотеть удалить память выделенную в другом потоке.

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

[ddv]

Про инлайн я вообще не понял? Я тоже знаю такое слово..

А то что в C++ программист может управлять inline генерацией, а в java в лучшем случае это попробует сделать VM и у вас НЕТ возможности помочь ей в этом потому что в byte code нет такой возможности

[nightmare2]

Ладно, господа. Вам задали написать систему управления ядерной станции. Или аэродромного локатора и диспетчерской службы. Или систему наведения антенн спутника. На чем будете писать?

Вполне можно написать на миксе, ЮИ и всякую бухгалтерию на джаве а то что поближе к железу на С, а вы это к чему спрашиваете?

Да так, обстановку разрядить Но я бы не стал писать даже UI для ядерной станции на джаве.

А на чем бы стали?
Неужто на C?

[Alexandr]

хехе, защитникам С++ стоит таки подучить остальное добро - C#, Java... а то рассуждения оч. странные
Место кассира на C# пишется в РАЗЫ быстрее... хех...

ЗЫ C++ без сомнения божественнен! но иногда (для достаточно большой ниши) быстрее и дешевле и _не хуже!_ сделать на шарпах и жабах

[Zombie416]

Да так, обстановку разрядить Но я бы не стал писать даже UI для ядерной станции на джаве.

Но его пишут. И даже Windows туда ставят, если судить по Stuxnet

И уж точно не на C++/C/... В авиации, помнится, Ada раньше использовалась.

[crypto5]

Про инлайн я вообще не понял? Я тоже знаю такое слово..

А то что в C++ программист может управлять inline генерацией, а в java в лучшем случае это попробует сделать VM и у вас НЕТ возможности помочь ей в этом потому что в byte code нет такой возможности

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

[ddv]

С чего это они не могут разбивать кучу на области для потоков?

Можно пруфлинк про такой менеджер памяти?

Я же написал что такой менеджер памяти в C++,бесполезен...поэтому его и нет. Но технически его можно сделать и никаких противопоказаний к этому нет...узнали thread id и выбрали нужную область из кучи.

[crypto5]

С чего это они не могут разбивать кучу на области для потоков?

Можно пруфлинк про такой менеджер памяти?

Я же написал что такой менеджер памяти в C++,бесполезен...поэтому его и нет. Но технически его можно сделать и никаких противопоказаний к этому нет...узнали thread id и выбрали нужную область из кучи.

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

[ddv]

А я вам написал почему не бесполезен

Вы написали "Я в этом не шибко разбираюсь" поэтому чтобы понять полезен он или нет надо разобраться. У вас есть ссылка но оригинал где описывается данный memory manager? Потому что навскидку я не нашел информации об этом в java.

[Zombie416]

А то что в C++ программист может управлять inline генерацией, а в java в лучшем случае это попробует сделать VM и у вас НЕТ возможности помочь ей в этом потому что в byte code нет такой возможности

В с++ программист может управлять этим весьма условно, советами. Послушает или нет его советов компилятор - как пойдет. В .NET-е точно так же - указывается у метода атрибут что он inline, а дальше компилятор в машинный код решает. В жабе, подозреваю, аналогично. И unreferenced private вызовы и переменные выбрасываются на раз два тоже.

Более того, предварительная компиляция всего проекта в нативный код до выполнения (и у .NET, и у Java она есть), совершенно необязательно дает улучшение производительности. А часто дает как раз наоборот - существенное ухудшение. Что и естестественно, т.к. C++ компилятор может оптимизировать только конкретный модуль, а не все что получается после сборки в целое.

[ddv]

В с++ программист может управлять этим весьма условно, советами. Послушает или нет его советов компилятор - как пойдет. В .NET-е точно так же - указывается у метода атрибут что он inline, а дальше компилятор в машинный код решает. В жабе, подозреваю, аналогично. И unreferenced private вызовы и переменные выбрасываются на раз два тоже.

Более того, предварительная компиляция всего проекта в нативный код до выполнения (и у .NET, и у Java она есть), совершенно необязательно дает улучшение производительности. А часто дает как раз наоборот - существенное ухудшение. Что и естестественно, т.к. C++ компилятор может оптимизировать только конкретный модуль, а не все что получается после сборки в целое.

Да не надо путать java компилятор и JIT. Это ДВЕ СОВЕРШЕННО РАЗНЫЕ вещи. Вы спросили какой информации нет у JIT - я вам ответил. И у java компилятора нет возможности передать эту информацию JIT. А выбросить методы без native компиляции не может ни java компилятор ни JIT.

[crypto5]

В с++ программист может управлять этим весьма условно, советами. Послушает или нет его советов компилятор - как пойдет. В .NET-е точно так же - указывается у метода атрибут что он inline, а дальше компилятор в машинный код решает. В жабе, подозреваю, аналогично. И unreferenced private вызовы и переменные выбрасываются на раз два тоже.

Более того, предварительная компиляция всего проекта в нативный код до выполнения (и у .NET, и у Java она есть), совершенно необязательно дает улучшение производительности. А часто дает как раз наоборот - существенное ухудшение. Что и естестественно, т.к. C++ компилятор может оптимизировать только конкретный модуль, а не все что получается после сборки в целое.

Да не надо путать java компилятор и JIT. Это ДВЕ СОВЕРШЕННО РАЗНЫЕ вещи. Вы спросили какой информации нет у JIT - я вам ответил. И у java компилятора нет возможности передать эту информацию JIT. А выбросить методы без native компиляции не может ни java компилятор ни JIT.

Выбрасывать не может, но может просто не компилировать неиспользуемые методы.

[crypto5]

А я вам написал почему не бесполезен

Вы написали "Я в этом не шибко разбираюсь" поэтому чтобы понять полезен он или нет надо разобраться. У вас есть ссылка но оригинал где описывается данный memory manager? Потому что навскидку я не нашел информации об этом в java.

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

[ddv]

Выбрасывать не может, но может просто не компилировать неиспользуемые методы.

Но место то они все равно в памяти расходуют...О чем мы вообще говорим? Вы мне утверждаете что JIT может лучше соптимизировать чем Native C++ компилятор, и тут же раскидываетесь кучей памяти под ненужные методы. А больше используемой памяти - большая возможность выхода за пределы кэша, что ведет к потери производительности намного больше чем недостаточная оптимизация кода.

[Boriskin]

Ладно, господа. Вам задали написать систему управления ядерной станции. Или аэродромного локатора и диспетчерской службы. Или систему наведения антенн спутника. На чем будете писать?

На коленке!

[ddv]

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

Например? Если я в чем то не уверен, то я говорю - возможно, может быть и т.п. а не требую предоставить тоже самое что то "незнаю как работающее" и вообще может быть несуществующее.
Мне просто стало интерестно как ФИЗИЧЕСКИ возможно сделать то что вы описали в Windows. По-моему это просто невозможно.

[crypto5]

Выбрасывать не может, но может просто не компилировать неиспользуемые методы.

Но место то они все равно в памяти расходуют...О чем мы вообще говорим? Вы мне утверждаете что JIT может лучше соптимизировать чем Native C++ компилятор, и тут же раскидываетесь кучей памяти под ненужные методы.
А больше используемой памяти - большая возможность выхода за пределы кэша, что ведет к потери производительности намного больше чем недостаточная оптимизация кода.

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

[Zombie416]

Да не надо путать java компилятор и JIT. Это ДВЕ СОВЕРШЕННО РАЗНЫЕ вещи. Вы спросили какой информации нет у JIT - я вам ответил. И у java компилятора нет возможности передать эту информацию JIT. А выбросить методы без native компиляции не может ни java компилятор ни JIT.

Да я не путаю. Как там дела обстоят в нюансах в жабе я не в курсе, но в .NET эта возможность есть. Можно запустить JIT предварительно для всего проекта и сгенерировать native код (ngen.exe). Улучшается время запуска. Производительность может как вырасти, так и упасть в зависимости от массы факторов.

Выбросить private методы без native компиляции вполне можно без последствий, еще на этапе получения bytecode.

Если в какой-то Java VM такой возможности нет, то наверняка есть и другие JVM в которых это есть.

[crypto5]

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

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

Про делегаты?