Здравствуйте, Algebroid, Вы писали:
A>Замануха — выставляют максимум, а потом обнижают. Или у автодилеров. В обычном маркете-универсаме платят как я сказал.
У меня как то доверия к реальным вакансиям больше, чем к твоим ничем не подкрепленным заявлениям.
Здравствуйте, Blazkowicz, Вы писали:
B>Здравствуйте, alex_public, Вы писали:
_>> в связи с окончанием периода роста производительности ядер процессоров. B>И никто не заметил что период роста производительности ядер плавно перетёк в период роста количества ядер? Или в C# не знают про векторизацию?
Синхронизация работы сборщика мусора на нескольких ядрах задача нетривиальная.
Здравствуйте, Blazkowicz, Вы писали:
B>Пара добавлений для новичков, кто пока дальше кода не видит.
B> Про более развитые языки, на которых "быстрее писать". Большинство ресурсов в длительных проектах уходит не на то чтобы написать, а на то чтобы разобраться с тем что уже написано и внести изменения. И тут у более простых языков есть небольшое преимущество. Простой язык — простой код — простые решения. Меньше не очевидных абстракций, которые скрывают в себе неисправимые реализации. Дешевле найти и замеменить разработчиков, так же как и обучить. По этим причинам, например, бум Scala прошел. Вытеснить древний и топорный язык Java с постамента никак не удаётся даже языкам опережающим по возможностям и C#.
В с++ помню человек писал с-подобным подходом, чтобы дойти до нужного метода сделал переход внутрь уровней на 10, т.к. одно действие — одна функция.
Получается если в системе есть сложное диалоговое окно, то чтобы раскурить логику надо много внутрь погружаться.
Цена Java программистов выше .Net.
B> Про производительность. Об этом твердят уже более десятка лет. Производительность в подавляющем большинстве систем на много менее критична чем масштабируемость. Стоимость времени квалифицированного разработчика соизмерима с самым топовым железом. Кому нужны недели оптимизаций, когда за те же деньги, можно купить железяку и решить проблему, а драгоценный ресурс — время потратить на более полезную для бизнеса задачу? Даже на самых топорных тестах .NET опережает Java, ну раза в два. При том что, если привести тесты в порядок, разница существенно сократится.
Ну вот stackoverlow написан на .net, там вроде все нормально у ребят при высоких нагрузках , хотя это не ентерпрайз, который как правило в интранете крутится.
B>Вот и выходит что ни развитость языка, ни производительность вообще никак на выбор платформы не влияют. Доступность, надежность, инструментарий и экономическя эффективность — вот что важно.
Вы самое главное забыли. Что мешает писать просто на C#?
Здравствуйте, Blazkowicz, Вы писали:
_>>А когда? ) Давай уже определимся: некий упомянутый тут термин (хыхы) "ранний JIT" — он что конкретно означает и где можно увидеть его определение? B>Бугагашечки. Мусье простыми словами не понимать? Только термины? B>Вот тут разжевано B>http://stackoverflow.com/a/35614237
Вижу по ссылке описание обычной работы JIT'а. А где там упоминания этого самого особенного "раннего JIT'a"? )
Здравствуйте, alex_public, Вы писали:
_>Вижу по ссылке описание обычной работы JIT'а. А где там упоминания этого самого особенного "раннего JIT'a"? )
Дурочком прикинулся? Объясняю. Для оптимизации времени запуска не все методы компилируются сразу. Некоторые раньше, некоторые позже.
Там где нужен быстрый запуск, методы откомпилируются скорее позже, чем раньше. А так же всякие ресурсоёмкие оптимизации тоже будет применены позже.
В то время, когда нужна максимальная производительность, JIT компиляция отработает раньше и с агрессивными оптимизациями, чтобы получить большую производительность, но ценой долгой инициализации системы. http://dic.academic.ru/dic.nsf/dic_synonims/149755/%D1%80%D0%B0%D0%BD%D0%BD%D0%B8%D0%B9
Здравствуйте, Blazkowicz, Вы писали:
_>> в связи с окончанием периода роста производительности ядер процессоров. B>И никто не заметил что период роста производительности ядер плавно перетёк в период роста количества ядер? Или в C# не знают про векторизацию?
Ну для начала векторизацией называют распараллеливание не с помощью процессорных ядер, а с помощью SIMD. И кстати с этой темой у Java всё довольно печально.
Далее, если говорить об увеличение количества ядер, то во-первых оно тоже сильно ограничено (кстати, насколько выросло количество ядер на твоём компьютере за последние 10 лет?) по ряду причин, а во-вторых большинство ПО пока так и не научилось эффективно использовать даже имеющиеся в наличие ядра. Причём часть ПО в силу своей специфики не научится никогда.
Здравствуйте, alex_public, Вы писали:
_>Ну для начала векторизацией называют распараллеливание не с помощью процессорных ядер, а с помощью SIMD. И кстати с этой темой у Java всё довольно печально. Хы-хы.
_>Далее, если говорить об увеличение количества ядер, то во-первых оно тоже сильно ограничено
CUDA? Не, не слышал такого.
_>(кстати, насколько выросло количество ядер на твоём компьютере за последние 10 лет?)
GPU — почти на порядок. И, интересно, при чем тут именно мой компьютер? Десктоп уже достиг того уровня, что большая производительность CPU ему нафиг не упала. Мне, например, просто не нужен проц быстрее.
_>а во-вторых большинство ПО пока так и не научилось эффективно использовать даже имеющиеся в наличие ядра. Причём часть ПО в силу своей специфики не научится никогда.
Речь опять о десктопе?
Здравствуйте, snaphold, Вы писали:
S>В с++ помню человек писал с-подобным подходом, чтобы дойти до нужного метода сделал переход внутрь уровней на 10, т.к. одно действие — одна функция. S>Получается если в системе есть сложное диалоговое окно, то чтобы раскурить логику надо много внутрь погружаться.
Некий единичный случай личного опыта выдаётся за обобщающий аргумент.
S>Цена Java программистов выше .Net.
Это обусловленно более высоким спросом на Java, а не требованиям к квалификации для полноценного использования языка.
S>Ну вот stackoverlow написан на .net, там вроде все нормально у ребят при высоких нагрузках , хотя это не ентерпрайз, который как правило в интранете крутится.
А что, кто-то говорит что у .NET всё плохо на нагрузках? Вы кроме производительности других факторов не видите принципиально?
S>Вы самое главное забыли. Что мешает писать просто на C#?
Ничего не мешает. Я вам просто указываю на несостоятельность выбранных вами критериев для сравнения.
Здравствуйте, Blazkowicz, Вы писали:
_>>Вижу по ссылке описание обычной работы JIT'а. А где там упоминания этого самого особенного "раннего JIT'a"? ) B>Дурочком прикинулся? Объясняю. Для оптимизации времени запуска не все методы компилируются сразу. Некоторые раньше, некоторые позже. B>Там где нужен быстрый запуск, методы откомпилируются скорее позже, чем раньше. А так же всякие ресурсоёмкие оптимизации тоже будет применены позже. B>В то время, когда нужна максимальная производительность, JIT компиляция отработает раньше и с агрессивными оптимизациями, чтобы получить большую производительность, но ценой долгой инициализации системы. B>http://dic.academic.ru/dic.nsf/dic_synonims/149755/%D1%80%D0%B0%D0%BD%D0%BD%D0%B8%D0%B9
Т.е. громким термином "ранний jit" ты обозвал всего лишь вариант тюнинга jvm опциями запуска? Понятненько...
Здравствуйте, alex_public, Вы писали:
_>Т.е. громким термином "ранний jit" ты обозвал всего лишь вариант тюнинга jvm опциями запуска?
Какого, нафиг, тюнинга? Это основное различие серверной и клиентской JVM.
_>Понятненько...
"Бобёр, выдыхай"
Здравствуйте, Blazkowicz, Вы писали:
_>>Ну для начала векторизацией называют распараллеливание не с помощью процессорных ядер, а с помощью SIMD. И кстати с этой темой у Java всё довольно печально. B>Хы-хы.
Ну и к чему ты разместил ссылку на полностью подтверждающую мои слова статью, в сочетание с подобным текстом? )
_>>Далее, если говорить об увеличение количества ядер, то во-первых оно тоже сильно ограничено B>CUDA? Не, не слышал такого.
CUDA — это не процессор, а один из вариантов работы с GPU. Видимо как раз GPU ты и хотел назвать? Но я тебя разочарую — там совсем другие ядра, не имеющие ничего общего с ядрами CPU. На них можно запустить только крайне ограниченный круг задач.
Относительно интересным промежуточным решением в этой области является Xeon Phi, который охватывает гораздо больший спектр задач. Но всё равно ещё достаточно специфических. Не говоря уже о его цене, габаритах и т.п.
_>>а во-вторых большинство ПО пока так и не научилось эффективно использовать даже имеющиеся в наличие ядра. Причём часть ПО в силу своей специфики не научится никогда. B>Речь опять о десктопе?
Нет, это про всё что угодно. Везде есть задачи, которые невозможно распараллелить.
Здравствуйте, alex_public, Вы писали:
_>Ну и к чему ты разместил ссылку на полностью подтверждающую мои слова статью, в сочетание с подобным текстом? )
С тем что "векторизация" несколько шире.
_>Но я тебя разочарую — там совсем другие ядра, не имеющие ничего общего с ядрами CPU. На них можно запустить только крайне ограниченный круг задач.
Спасибо, Кэп, я в курсе.
_>Относительно интересным промежуточным решением в этой области является Xeon Phi, который охватывает гораздо больший спектр задач. Но всё равно ещё достаточно специфических. Не говоря уже о его цене, габаритах и т.п.
Да, ну вот прям так сразу Xeon Phi. 16 ядер уже не показатель?
_>Нет, это про всё что угодно. Везде есть задачи, которые невозможно распараллелить.
Везде есть какие-то специфические задачи, под которые можно подогнать любые аргументы.
Речь о массовом производстве ПО:
десктопы — производительность далеко опережает требования ПО
портативные устройства — по производительно не сильно отстают от десктопа. Шарпу, тут крыть особо не чем с его мобильной виндой. Да, и яве гордиться тоже.
сервера — чудесно масштабируются по железу. Вообще без проблем.
молотилки массивов данных — масштабируются чуть хуже чем сервера, но вполне реально
прочее миниатюрное железо — все туда стремятся, но никто ещё плотно нишу не окупировал, так что из сравнения вычеркивается.
Поэтому то что где-то там есть какие-то там задачи, которые плохо масштабируются по железу, вообще никак не характиризует ситуацию на рынке.
Здравствуйте, Blazkowicz, Вы писали:
_>>Т.е. громким термином "ранний jit" ты обозвал всего лишь вариант тюнинга jvm опциями запуска? B>Какого, нафиг, тюнинга? Это основное различие серверной и клиентской JVM.
Здравствуйте, alex_public, Вы писали:
_>>>Т.е. громким термином "ранний jit" ты обозвал всего лишь вариант тюнинга jvm опциями запуска? B>>Какого, нафиг, тюнинга? Это основное различие серверной и клиентской JVM. _>http://www.oracle.com/technetwork/java/whitepaper-135217.html#2 — сумеешь сам подсчитать, сколько раз там используется слово tuned? )))
Облажался — притворись валенком. Какой отношение "тюнинг" проведённый инженерами Oracle для оптимизации работы JVM имеет отношение к "тюнингу jvm опциями запуска".
Ах, и то и другое — "тюнинг". Черный пояс по сове и глобусу.
Здравствуйте, Blazkowicz, Вы писали:
_>>Ну и к чему ты разместил ссылку на полностью подтверждающую мои слова статью, в сочетание с подобным текстом? ) B>С тем что "векторизация" несколько шире.
Ну расскажи какая же ещё векторизация кроме SIMD существует. )))
_>>Нет, это про всё что угодно. Везде есть задачи, которые невозможно распараллелить. B>Везде есть какие-то специфические задачи, под которые можно подогнать любые аргументы.
Вообще то нельзя распараллелить как раз очень большое число задач. Просто пока что далеко не все из них страдают нехваткой быстродействия.
B>Речь о массовом производстве ПО: B>десктопы — производительность далеко опережает требования ПО
Дааа? ) А почему тогда на моём топовом Xeon'е тормозят банальные сайтики в браузере? ) Ну точнее я то знаю ответ на этот вопрос (надо вводить разрешение на работу в IT отрасли), но ты же утверждаешь что никак подобных тормозов нет и близко.
B>портативные устройства — по производительно не сильно отстают от десктопа.
Ну ну.
B>сервера — чудесно масштабируются по железу. Вообще без проблем.
Сервера чудесно масштабируются покупкой ещё нескольких серверов рядом. Но такая система налагает определённые жёсткие требования на ПО. А масштабирование одиночного сервера — это как раз дико не выгодный процесс. Но на который многие идут из-за того, что их ПО (чаще всего какие-нибудь РСУБД и т.п.) не умеет масштабироваться на много машин.
B>молотилки массивов данных — масштабируются чуть хуже чем сервера, но вполне реально
Вот как раз в этой области никаких проблем нет, т.к. там всё отлично распараллеливается.
Здравствуйте, alex_public, Вы писали:
_>Ну расскажи какая же ещё векторизация кроме SIMD существует. )))
Ладно. Уболтал. Будем считать что не всякое распараллеливание есть векторизация. Хотя разница только в способе реализации. По сути — одно и то же.
_>Вообще то нельзя распараллелить как раз очень большое число задач. Просто пока что далеко не все из них страдают нехваткой быстродействия.
Конкретики ждать не приходится.
_>Дааа? ) А почему тогда на моём топовом Xeon'е тормозят банальные сайтики в браузере? ) Ну точнее я то знаю ответ на этот вопрос (надо вводить разрешение на работу в IT отрасли), но ты же утверждаешь что никак подобных тормозов нет и близко.
Не из-за процессора.
_>Ну ну.
Баранки гну.
_>Сервера чудесно масштабируются покупкой ещё нескольких серверов рядом. Но такая система налагает определённые жёсткие требования на ПО. А масштабирование одиночного сервера — это как раз дико не выгодный процесс. Но на который многие идут из-за того, что их ПО (чаще всего какие-нибудь РСУБД и т.п.) не умеет масштабироваться на много машин.
Даже проблема "немасштабируемых РСУБД" вполне себе частично решается железом. Ну, и про сервер вообще можно было бы не вспоминать. Про менеджмент потоков в винде легенды ходят.
B>>молотилки массивов данных — масштабируются чуть хуже чем сервера, но вполне реально _>Вот как раз в этой области никаких проблем нет, т.к. там всё отлично распараллеливается.
Ну, вот, ты по всем пунктам согласен.
Здравствуйте, Blazkowicz, Вы писали:
_>>http://www.oracle.com/technetwork/java/whitepaper-135217.html#2 — сумеешь сам подсчитать, сколько раз там используется слово tuned? ))) B>Облажался — притворись валенком. Какой отношение "тюнинг" проведённый инженерами Oracle для оптимизации работы JVM имеет отношение к "тюнингу jvm опциями запуска". B>Ах, и то и другое — "тюнинг". Черный пояс по сове и глобусу.
Прямо по той же ссылке:
The JDK contains both of the these systems in the distribution, so developers can choose which system they want by specifying -client or -server.
Although the Server and the Client VMs are similar, the Server VM has been specially tuned to maximize peak operating speed. It is intended for executing long-running server applications, which need the fastest possible operating speed more than a fast start-up time or smaller runtime memory footprint.
_>The JDK contains both of the these systems in the distribution, so developers can choose which system they want by specifying -client or -server.
_>Although the Server and the Client VMs are similar, the Server VM has been specially tuned to maximize peak operating speed. It is intended for executing long-running server applications, which need the fastest possible operating speed more than a fast start-up time or smaller runtime memory footprint.
Назвать "тюнингом" переключение между двумя JVM, это и есть натягивание совы на глобус.
_>Дааа? ) А почему тогда на моём топовом Xeon'е тормозят банальные сайтики в браузере? ) Ну точнее я то знаю ответ на этот вопрос (надо вводить разрешение на работу в IT отрасли)
О, голос разума в треде. Даёшь орден айтишников! так же, как это сделано у медиков и юристов с их адвокатурой и проч.
