Комментарии 160
NetCracker OS
А что значит аббревиатура OS в этом контексте?
То есть из четырех экспертов никто не оценил Java, как быструю. Скорее, как достаточную и удовлетворяющую. Это вполне себе показательно.
А по-моему наоборот, миф о быстродействии Java упорно сквозил в тексте… Вообще маркетологи Java в этом плане постарались на славу.
Я не считаю это большой проблемой. Интерпретируемые языки ещё более медленные, тем не менее, они активно используются в серверном программировании.
Дело в том, что стоимость разработки ПО на Java ниже, чем на C++. Пока выгодно увеличивать мощность серверов, а не платить втридорога за быстрый код, ситуация будет именно такой.
Дело в том, что стоимость разработки ПО на Java ниже, чем на C++. Пока выгодно увеличивать мощность серверов, а не платить втридорога за быстрый код, ситуация будет именно такой.
Просто качественный код на С/С++ почти всегда быстрее качественного кода на Java. Но и недооценивать джавовый оптимизатор не нужно — разница частенько измеряется в единицах процентов.
50 гигабайт, но чаще и того меньше: от 4 до 8 гигабайт на приложение.
И всё таки я не могу понять этот момент. Язык не может гарантированно быстро работать с оперативной памятью. Сегодня, можно подключать данные в памяти обходными путями. В девятой версии, возможно так не получится.
Как такой язык может быть лучшим выбором для серверного ПО?
Java позволяет писать качественные приложения быстро. И Java позволяет при приложении некоторых усилий писать быстрые приложения. За это ее и любят.
Давайте похоливарим. Любой программист на хабре, не пользующийся Visual Studio и vim, на вопрос «что у вас на машине жрет 100500 гигабайтов памяти и столько же процессора» ответит — моя любимая IDE на Java.
Все enterprise-Java системы — неповоротливые монстры, запускающиеся по 5-10 минут, и потом так же медленно жующие данные (привет «любой Hadoop-зоопарк из Java приложений, Druid и т.д.).
При всем при этом, вокруг Java создан устойчивый миф о „быстродействии“, настолько распространенный, что даже данная статья стала возможной (сравнение C и Java пфф..)
Все enterprise-Java системы — неповоротливые монстры, запускающиеся по 5-10 минут, и потом так же медленно жующие данные (привет «любой Hadoop-зоопарк из Java приложений, Druid и т.д.).
При всем при этом, вокруг Java создан устойчивый миф о „быстродействии“, настолько распространенный, что даже данная статья стала возможной (сравнение C и Java пфф..)
Давайте похоливарим.
Даже прочитав разные мнения в стартпосте можно понять, что холивара не будет. Андрей Паньгин не парится, если приложение на ноде потребляет больше 8 гб., то пора думать о второй ноде. Его устраивает такая производительность! Владимир Ситников не парится, если он видит проблемы со скоростью работы приложения (алгоритма), то он внимательно разбирается в сути проблемы и часто оказывается, что приложение делает тысячи sql запросов. При этом java программисты (которых кстати много) не при чем, это им ТЗ дали неверное. Кстати, dba программиста, который еще на этапе тестирования такого «серверного» приложения должен приходить и ругаться (мол, что вы базу так грузите, и что с того что база тестовая, вы что потом такое в продакшен выпустите) видимо нет совсем.
И только Олег Краснов жалеет, что мало открытого рабочего кода на С, который можно просто скопировать, мало. И еще не хватает ему С иногда требуется ассемблер. Он java для своих «высокопроизводительных» задач не рассматривает совсем.
А вы посмотрите на любого другого «монстра» из миров других языков. По большему счету, все утверждения можно будет просто перенести, сменив названия на нужные. В языке ли дело?
> что у вас на машине жрет 100500 гигабайтов памяти и столько же процессора
вы удивитесь, но это у меня это хром + фаерфокс.
вы удивитесь, но это у меня это хром + фаерфокс.
Из того, что IDE делают на java и они тормозят и жрут память, не следует, что виновата именно java. Там просто много функционала различного, вот и тормозит, и память жрет. Всякие проверки синтаксиса, проверки грамматики и тд… В vim этого всего нет. Если сделать vim на java — он тоже тормозить не будет, просто это никому ненадо.
А в Студии?
Не имею ни малейшего понятия. Могу лишь предположить, что если студия тоже тормозит, то, вероятно, там то же самое — виноват не шарп.
Вообще, мы когда-то в другой эпохе (помоему даже до Януковича ;) ) пробовали как-то сравнивать шарп с жавой. Скорость шарпа была где-то на уровне жавовского С1 из java6. Но сейчас расклады наверняка другие.
Вообще, мы когда-то в другой эпохе (помоему даже до Януковича ;) ) пробовали как-то сравнивать шарп с жавой. Скорость шарпа была где-то на уровне жавовского С1 из java6. Но сейчас расклады наверняка другие.
Так вот, 2015 студия, открыт проект cocos2d-x-3.6, 15 случайных файлов. Потребляет 350Мб + 6 несколько процессов IntelliSense, которые, хоть и умеют вырастать до неприличия, всё-таки обычно ведут себя скромно — по 100Мб — да и могут быть убиты без непоправимого вреда здоровью (в смысле, сокращены до 1 процесса, тогда анализ и разукрашивание кода немного замедлятся). Итого чуть более 700 Мб, который со временем скукоживается в 450.
Для сравнения, напомню, IDEA на 32-битных убунтах просто не существует. NetBeans сравнить не могу за не имением живого экземпляра оного.
Что до скорости шарпов, напомню, есть такая игра, Terraria зовётся. На шарпах написана. С производительностью там порядок. А Minecraft в своей Story mode переехал с Явы на луа, так как даже он оказался более портируемым и производительным. Хотя, дело, наверное, в пристрастиях студии и изначальном говнокоде автора.
Для сравнения, напомню, IDEA на 32-битных убунтах просто не существует. NetBeans сравнить не могу за не имением живого экземпляра оного.
Что до скорости шарпов, напомню, есть такая игра, Terraria зовётся. На шарпах написана. С производительностью там порядок. А Minecraft в своей Story mode переехал с Явы на луа, так как даже он оказался более портируемым и производительным. Хотя, дело, наверное, в пристрастиях студии и изначальном говнокоде автора.
NetBeans жрет примерно 400-500мб. Насчет IDEA. У них весьма непонятная политика компании — под каждый чих выделять отдельный процесс с отдельной jvm. Отсюда и потребляемая память. Видимо, они себе память понакупали — и жируют. С 2гигами работает печальненько, 4гига — можно жить. У меня на работе 4гига и 64 система. Полет нормальный, ff или хром все равно жрут больше.
Ну, хром… Я, конечно, вспоминаю старую оперу со скупой слезой сожаления, но разве современный интернет способен НЕ выжирать всю память?
IDEA правда странная, но таки щито поделать? В конце концов, никто не без греха, те же бобы значительно уступают в мощи рефакторинга и анализатора как идее в жабе, так и студии в плюсах. Студия в полной сборке тащит под 50Гб хабара, включая виртуальные машины десятки, хрени, андроида, вместе со всеми сдк, ндк и тп. Спасибо, что ставится тихо, глючит не сильно, да и не тормозит почти. А вим нужен выбражалам. Нет, я не против вима, я против выбражал.
А закончу я старым еврейским анекдотом. Выходит Иисус в толпу и говорит: Таки кто без греха, пусть бросит в меня камень! Ай, мама, ну больно же! Сколько я просил не приходить и не мешать мне работать?!
Так и тут, только любимые инструменты мы знаем настолько хорошо, чтобы отбить у окружающих желание их использовать.
IDEA правда странная, но таки щито поделать? В конце концов, никто не без греха, те же бобы значительно уступают в мощи рефакторинга и анализатора как идее в жабе, так и студии в плюсах. Студия в полной сборке тащит под 50Гб хабара, включая виртуальные машины десятки, хрени, андроида, вместе со всеми сдк, ндк и тп. Спасибо, что ставится тихо, глючит не сильно, да и не тормозит почти. А вим нужен выбражалам. Нет, я не против вима, я против выбражал.
А закончу я старым еврейским анекдотом. Выходит Иисус в толпу и говорит: Таки кто без греха, пусть бросит в меня камень! Ай, мама, ну больно же! Сколько я просил не приходить и не мешать мне работать?!
Так и тут, только любимые инструменты мы знаем настолько хорошо, чтобы отбить у окружающих желание их использовать.
2-4ГБ памяти — у вас там что, телефон для программирования? Вообще оперативки на машинах разработчика уже давно-давно меньше 16ГБ быть не должно. И остальные комплектующие должны быть нормальными, в том числе и SSD уже давно стандарт де-факто. Зачем вообще работать там, где вам даже не могут обеспечить рабочее места?
Думаю, что на нормальном железе IDEA летает просто.
PS Сам я на плюсах пишу, и использую QtCreator в качестве IDE, т.ч. проблем с оперативкой или скоростью работы IDE никогда не испытывал :)
Думаю, что на нормальном железе IDEA летает просто.
PS Сам я на плюсах пишу, и использую QtCreator в качестве IDE, т.ч. проблем с оперативкой или скоростью работы IDE никогда не испытывал :)
Скажи, что мне ещё и с сокета AM2 переезжать пора, да? И что DDR2 уже не торт? И что GeForce 8500 GT уже не подходит для куд-CUDA? Что IDE ушёл навсегда, и бухгалтерия не должна хранить отчёты на дискетах?
Ну же, скажи, что закон Мура не собирается остановиться!
А если серьёзно, программисты придумывают способы понизить производительность программ гораздо быстрее, чем учёные — повысить. Надо бы быть ответственнее.
PS Сам я на плюсах пишу, и использую QtCreator в качестве IDE, т.ч. проблем с оперативкой или скоростью работы IDE никогда не испытывал :)
Ну же, скажи, что закон Мура не собирается остановиться!
А если серьёзно, программисты придумывают способы понизить производительность программ гораздо быстрее, чем учёные — повысить. Надо бы быть ответственнее.
PS Сам я на плюсах пишу, и использую QtCreator в качестве IDE, т.ч. проблем с оперативкой или скоростью работы IDE никогда не испытывал :)
А зачем? Чем позже заапгрейдишься — тем больше денег сэкономишь. Если компа хватает — это ок, и апгрейдить его ненадо.
Самое главное — это не чтобы хотя бы 2 монитора было, а с 4 гигами пока еще можно нормально жить.
Самое главное — это не чтобы хотя бы 2 монитора было, а с 4 гигами пока еще можно нормально жить.
Что до скорости шарпов, напомню, есть такая игра, Terraria зовётся
Смотрите более серьёзные игры: Cities Skyline, например.
Написана также на C#, работает под Mono (в т.ч. и под Windows) — никаких проблем с производительностью нет и плюс к портируемости.
Minecraft в своей Story mode переехал с Явы на луа
Minecraft Story mode это интерактивная новелла от TellTale? Логично, что для адвентюр, квестов и новелл выбирают Lua или python. Но при чём здесь первоначальный Minecraft, который на java?
Там виноваты COM и 32-битность самой VS, т. е. 3,5Гб должно хватить всем: и студийному GUI, и Roslyn'у, и Resharper'у, и прочим плагинам студии, что живут в том же процессе.
По вашему, программисты на Хабре — сплошные ретрограды. У современного человека 90% памяти на компе сжирают мутные процессы под названием Chrome Helper, Slack и прочие поделия на основе Electron. 300 мегабайт за вкладку с HTML — норма.
Java при всей ее любви к памяти не способна угнаться за Blink, и любимая IDE соседствует с маленьким и скромным хипстерским музыкальным плеером или приложением для заметок.
Java позволяет писать качественные приложения быстро.
На других языках пишут некачественные приложения и медленно?
И Java позволяет при приложении некоторых усилий писать быстрые приложения.
С оперативной памятью работают с помощью внешней библиотеки! Вот это я понимаю «некоторые усилия».
Хотя большого значение мои «непонимания» не имеют, раз java используется и программистов, а не только менеджеров, всё устраивает — то так тому и быть.
Мне любопытно. Не секрет, что многие гос. сайты и сервисы в РФ активно используют java. Не возможен ли такой час Х, когда компания oracle будет судиться с подрядными организациями создающими данные сайты за «9 строчек кода», например. Дело может и не выиграют, но по судам затаскают. Или волноваться необходимо только google для других компаний и частных лиц такой проблемы нет?
НЛО прилетело и опубликовало эту надпись здесь
С оперативной памятью работают с помощью внешней библиотеки
Не путайте, не "работают", а конкретно apangin работает. У них там такие адовые нагрузки, что без этого нельзя. Мало в мире Java-систем, которым приходится обрабатывать больше данных, чем Одноклассникам. Я думаю, в топ-10 они вполне могут входить. Потому и ухищрения такие. Большинству это не нужно.
Так же хочется добавить, что из коробки java тоже умеет работать с памятью без всяких приседаний. У этого решения есть свои особенности, но даже если не брать в расчет, что почти любые инструкции java это работа с памятью и принять версию, что имеется ввиду работа с сырой памятью, говорить, что java для этого нужна отдельная либа — неверно.
Там довольно извратное управление памятью, чтобы это было фичей общего назначения. Одного взгляда на код reserveMemory должно хватить, чтобы вызвать рвотный эффект.
Тонкость в том, что стандартная библиотека не позволяет явно деаллоцировать память. В противном случае могли бы утечь указатели на деаллоцированную память, что нормальная Java всё же позволить не может. Поэтому деаллокация полагается на стандартный GC, который соберёт ваши хиповые DirectByteBuffer'ы и через PhantomReference (это такой finalize на стероидах) уже освободит off-heap-память. Трудность в том, что у вас в хипе может быть полно места и GC может и не вызываться, а off-heap-память при этом закончится. Отсюда такие странные приседания в reserveMemory.
В общем, DirectByteBuffer надо использовать осторожно и только на ограниченном круге задач. Часто безопаснее ограничиться memory-mapped-файлами, которые могут спокойно выгружаться из памяти.
Все эти холивары бессмысленны, вопрос лежит в плоскости выше.
Более того, я бы отметил, что Java удивительна еще своей скоростью при тех требованиях что на нее возложены.
Когда вам надо сверхбезопасную среду, по памяти, по вычислениям, кроссплатформенную. Вы не хотите вникать в энтропию проблем которые роятся вокруг разнородных платформ — вы «лиса и хотите фыр-фыр» ©. Если у вас бизнес-задача, где приоритетом является максимальная и параноидальная детерминированность процесса — и цена ошибки выше цены скорости ее выполнения (банки, крупные предприятия) — то очевидно, что Java умеющая правиальную финансовую математику, дотошные проверки, самопроверки, огромную иерархию объектов с тестированием, самотестированием, с аспектными срезами — это ваш выбор.
И ясно что даже если вы сами все это напишите на C++ (что вряд ли) — то получите ту же скорость (а в силу отсутствия у вас сил и скиллов на кв.метр — скорее всего и хуже).
Или простой ответ: вам надо доехать в танке с подушками безопасности и катапультирующейся титановой капсулой на самый крайний момент — ваш выбор Java. Вы едете угрюмо по скорости, но весьма комфортно и спите спокойно, даже за рулем. Или вы хотите просто переехать высокоскоростную магистраль на скейте? Чтобы доставить пиццу? — возможно ваш выбор C++
Более того, я бы отметил, что Java удивительна еще своей скоростью при тех требованиях что на нее возложены.
Когда вам надо сверхбезопасную среду, по памяти, по вычислениям, кроссплатформенную. Вы не хотите вникать в энтропию проблем которые роятся вокруг разнородных платформ — вы «лиса и хотите фыр-фыр» ©. Если у вас бизнес-задача, где приоритетом является максимальная и параноидальная детерминированность процесса — и цена ошибки выше цены скорости ее выполнения (банки, крупные предприятия) — то очевидно, что Java умеющая правиальную финансовую математику, дотошные проверки, самопроверки, огромную иерархию объектов с тестированием, самотестированием, с аспектными срезами — это ваш выбор.
И ясно что даже если вы сами все это напишите на C++ (что вряд ли) — то получите ту же скорость (а в силу отсутствия у вас сил и скиллов на кв.метр — скорее всего и хуже).
Или простой ответ: вам надо доехать в танке с подушками безопасности и катапультирующейся титановой капсулой на самый крайний момент — ваш выбор Java. Вы едете угрюмо по скорости, но весьма комфортно и спите спокойно, даже за рулем. Или вы хотите просто переехать высокоскоростную магистраль на скейте? Чтобы доставить пиццу? — возможно ваш выбор C++
Понятное дело, что сравнивать Java и C++ нельзя. А вот холивар Java vs C# был бы более интересен, особенно учитывая то, что глядя на код, не всегда легко понять, на каком языке он написан.
Я работаю преимущественно в науке, а не в продакшене. При этом мне больше нравится C#, потому что
1. Скорость эволюции C# как языка выше, чем у консервативной Java. Те же лямбды в Java появились только через 6 лет после C#. А мегаудобного для сетевых приложений асинхронного программирования в Java пока ещё нет.
2. Удобная визуальная среда для разработки GUI приложений в отличие от зоопарка GUI-библиотек в Java. А за счёт Mono — ещё и кросс-платформенная.
3. Удобная и быстрая IDE, бесплатная для некоммерческого использования.
4. Лёгкость подключения кода из нативных библиотек.
При этом я понимаю, что инфраструктура Java в целом более богата и свободна. Но пока она не нужна — .NET устраивает.
Я работаю преимущественно в науке, а не в продакшене. При этом мне больше нравится C#, потому что
1. Скорость эволюции C# как языка выше, чем у консервативной Java. Те же лямбды в Java появились только через 6 лет после C#. А мегаудобного для сетевых приложений асинхронного программирования в Java пока ещё нет.
2. Удобная визуальная среда для разработки GUI приложений в отличие от зоопарка GUI-библиотек в Java. А за счёт Mono — ещё и кросс-платформенная.
3. Удобная и быстрая IDE, бесплатная для некоммерческого использования.
4. Лёгкость подключения кода из нативных библиотек.
При этом я понимаю, что инфраструктура Java в целом более богата и свободна. Но пока она не нужна — .NET устраивает.
- scala
- javafx+scene builder
- IntelliJ IDEA
- JNR
1. Не пробовал — я немного ксенофоб.
2. Ну где ж оно раньше было?
3. Один раз попробовал, но не IDEA, а CLion (ядро то же самое). По сравнению с MSVS оказался неповоротливыми и тормозящим монстром (для Core i7 с PCI-E SSD это непозволительно). Удобство написания кода играет далеко не последнюю роль при выборе языка программирования.
4. Не слышал, спасибо.
Получается, что принициальных различий нет, а выбор языка — дело вкуса. Выбирал по удобству IDE. Менять одно на другое точно такое же смысла не вижу.
2. Ну где ж оно раньше было?
3. Один раз попробовал, но не IDEA, а CLion (ядро то же самое). По сравнению с MSVS оказался неповоротливыми и тормозящим монстром (для Core i7 с PCI-E SSD это непозволительно). Удобство написания кода играет далеко не последнюю роль при выборе языка программирования.
4. Не слышал, спасибо.
Получается, что принициальных различий нет, а выбор языка — дело вкуса. Выбирал по удобству IDE. Менять одно на другое точно такое же смысла не вижу.
Насколько мне известно, IDEA и CLion — весьма разные вещи, у них кодовая база слабо пересекается, так исторически сложилось. IDEA на голову выше, про CLion ребята из JetBrains сами говорили, что он далёк от того, чтобы его называть "классной IDE".
Ситуация с MSVS, как я понимаю, сейчас как раз обратная. JetBrains всё сложнее впиливать новые фичи в решарпер, то и дело возникают костыли и подводные камни. 32-битность ещё постоянно бьёт в темечко. Не случайно они разрабатывают Rider — UI IDEA на джаве, а внутри сервисом крутится ядро из решарпера. Было б удобнее всё иметь на Java, но больно много крутого кода в решарпере на C# уже написано, который переписать на Java просто нереально, поэтому такая химера возникла. При этом несмотря на химерность, JetBrains вкладывается в это решение, потому что в перспективе идеевский фронтэнд лучше, чем MSVS.
Я с удовольствием попробую Rider и оценю его возможности, но только когда он выйдет. Решарпером не пользуюсь — мне с ним оказалось некомфортно. Очень надеюсь, что в Rider не будет проблем с производительностью.
Правда, у меня есть ещё одно требование: возможность работы и одновременной отладки C#/Java/Scala и C++ кода в одной IDE. Так что IDEA отпадает совсем, остаётся Eclipse против MSVS. Функционал последней побогаче будет.
Правда, у меня есть ещё одно требование: возможность работы и одновременной отладки C#/Java/Scala и C++ кода в одной IDE. Так что IDEA отпадает совсем, остаётся Eclipse против MSVS. Функционал последней побогаче будет.
Райдер сейчас летает. А вот насчет одновременной отладки разного кода — эту задачу кажется пока еще никто не решил.
Да, я уже попробовал Rider, и он мне в целом понравился.
А насчёт одновременной отладки C# и C++ — эта возможность есть и всегда была в Visual Studio.
А насчёт одновременной отладки C# и C++ — эта возможность есть и всегда была в Visual Studio.
Уж и Java то прощаем сквозь закрытые пальцы ее пропритеарные щупальца Oracle, но хотя бы нет вендор-лока на ОСь, но с C# вы на поводке .NET и MS, а это уже никак не может быть правильным, особенно в Sci-деве. Не знаю, что у вас за наука, но в научных кругах я слышал тягу к более академичным вариантам. Ну хотя бы Python. Хотя быстрым его не назовешь. Но наука традиционно не тороплива.
Так и C# — это просто язык. Вендор-лок распространяется на ряд библиотек и технологий, но не сам рантайм, исходники которого выложены в открытый доступ.
Для обмена кода в научной среде удобно использовать лаконичные скриптовые языки: Python, Matlab. Правда, использование Matlab я осуждаю, т.к. это проприетарный продукт с высокой стоимостью лицензии.
Но для себя и заказчиков все равно приходится реализовывать алгоритмы на C/C++, иногда даже с использованием CUDA, потому что Python — это только прототипирование, для реальных применений он не годится.
Для обмена кода в научной среде удобно использовать лаконичные скриптовые языки: Python, Matlab. Правда, использование Matlab я осуждаю, т.к. это проприетарный продукт с высокой стоимостью лицензии.
Но для себя и заказчиков все равно приходится реализовывать алгоритмы на C/C++, иногда даже с использованием CUDA, потому что Python — это только прототипирование, для реальных применений он не годится.
Холивар Java vs C# будет в следующем эпизоде Разбора Полётов (не в ближайшем, который завтра, а в том, который после него). На секундочку Саша Гольдштейн vs Лёша Шипилёв.
>сверхбезопасную среду, по памяти, по вычислениям
А в чем выражается безопасность по вычислениям?
А в чем выражается безопасность по вычислениям?
Скорее, в чём выражается сверхбезопасность, а не просто безопасность?
Рискну предположить, что безопасность по вычислениям заключается в отсутствии неявных преобразований типов, которые могут привести к потере точности или неоднозначному поведению, а также отсутствии прямого доступа к содержимому переменных: например, вычисление abs(float) можно делать просто сбрасывая старший бит в битовом представлении числа.
Рискну предположить, что безопасность по вычислениям заключается в отсутствии неявных преобразований типов, которые могут привести к потере точности или неоднозначному поведению, а также отсутствии прямого доступа к содержимому переменных: например, вычисление abs(float) можно делать просто сбрасывая старший бит в битовом представлении числа.
НЛО прилетело и опубликовало эту надпись здесь
>Скорее, в чём выражается сверхбезопасность, а не просто безопасность?
Точно =)
Т.е. сверхбезопасность заключается в запрете неявного каста из типа большей точности в тип с меньшей?
Если честно, то я думал об отлове в рантайме всяких 1.0/0.0, sqrt(-10.0) и т.д.
Точно =)
Т.е. сверхбезопасность заключается в запрете неявного каста из типа большей точности в тип с меньшей?
Если честно, то я думал об отлове в рантайме всяких 1.0/0.0, sqrt(-10.0) и т.д.
Если честно, то я думал об отлове в рантайме всяких 1.0/0.0, sqrt(-10.0) и т.д.
А эта штука вообще идёт параллельно и определяется не языком, а режимом работы FPU.
НЛО прилетело и опубликовало эту надпись здесь
Тем не менее, мне ничто не мешает в процессе работы программы эти исключения взять и включить с помощью платформо-зависимых вызовов. Недокументированная возможность и грязный хак? Возможно. Не знаю, как JVM, но .NET, где логика работы с FP точно такая же, абсолютно корректно обрабатывает эти исключения.
В продакшене такое, конечно, не стоит использовать, а вот для отладки математических алгоритмов для точной локализации проблемного места — почему бы и нет?
В продакшене такое, конечно, не стоит использовать, а вот для отладки математических алгоритмов для точной локализации проблемного места — почему бы и нет?
Извените, но если вы хотите именно «сверхбезопасность» по вычислениям, работе с ресурсами (и памятью в частности) и работе с многопоточностью, то вам однозначно стоит посмотреть в сторону Rust, а не Java. Там эта сверхбезопасность будет на порядок выше. Хотя и надо признаться, что язык еще молодой и разработка на нем будет медленнее раза в 2-3 в силу отсутствия продвинутого туллинга. Но что не сделаешь ради сверхбезопасности? Не так ли?
СЗОТ.
Не про Java и не C++.
Дмитрий, mezastel, два года назад Вы спрашивали про парсер FIX'a в FPGA и очень хотели не писать на VHDL этот парсер.
В итоге, Вы использовали MATLAB для парсинга или начали «перекладывать битики» с помощью «старого языка» VHDL?
Не про Java и не C++.
Конечно, для FPGA разработки я использую или VHDL напрямую или пишу MATLAB, который после конверсии VHDL выбрасывает — суть остается та же.
Дмитрий, mezastel, два года назад Вы спрашивали про парсер FIX'a в FPGA и очень хотели не писать на VHDL этот парсер.
В итоге, Вы использовали MATLAB для парсинга или начали «перекладывать битики» с помощью «старого языка» VHDL?
----Опять же, в С++ такая проблема, что самых базовых вещей нет в стандартной библиотеке. И это новичка, которому нужно перевести строку, допустим, в нижний регистр или побить по токенам, просто приведет в ступор.
Или я что-то не понимаю?
http://en.cppreference.com/w/cpp/string/byte/tolower
Или я что-то не понимаю?
http://en.cppreference.com/w/cpp/string/byte/tolower
Это для одного символа. Для всей строки не так просто:
std::transform(s.begin(), s.end(), s.begin(), std::tolower);
Для одного символа — да, есть. Для строки — извольте писать сами или boost::to_lower(_copy), причем все это глобальные функции, то есть чтобы найти ее, нужно знать что она вообще существует.
И что, даже русский UTF-8 правильно сконвертирует?
Нет, не сконвертирует. Нужно сначала перевести строку из UTF-8 во внутреннюю single-byte кодировку (wchar_t). Кстати, в Java и C# точно такая же ситуация.
Нужно сначала перевести строку из UTF-8 во внутреннюю single-byte кодировку (wchar_t). Кстати, в Java и C# точно такая же ситуация.Какая такая же? Куда надо в Java и C# что-то переводить из String, чтобы сделать tolower?
Какая такая же? Куда надо в Java и C# что-то переводить из String, чтобы сделать tolower?
Сначала конвертируем из UTF-8 byte array в string, затем делаем операции над строкой, затем делаем обратное преобразование.
И в C#, и в Java, и в C++ (wstring) символьный тип имеет фиксированный размер (16 бит). Так что можно считать, что внутреннее представление строк — это UTF-16 с игнорированием суррогатных пар.
Да, выше написал неточно: не single-byte, конечно.
Не, ну это-то всё правильно. Но обычно строки здесь внутри приложения обрабатываются всё же в виде «строки», которая скрывает реализацию (по сути это wchar/UCS2 какой-нибудь, да). И в байты/обратно (это в том числе о utf-8 или о любой другой кодировке) переводится только в момент ввода-вывода. Т.е. чтобы приходилось в Java байты переводить в string, потом делать операции строковые, а потом сразу обратно в байты — я с ходу затрудняюсь припомнить такой случай в своей практике.
upd Вот на C++ такое случалось, но и то, в «современном» C++ это тоже некомильфо как-то (современный — это после 00х).
upd Вот на C++ такое случалось, но и то, в «современном» C++ это тоже некомильфо как-то (современный — это после 00х).
Да, преобразование строки в конкретной кодировке из байтового представления во внутреннее представление и обратно обычно делают всякие StreamReader-ы и StreamWriter-ы. В C++ же потоки не поддерживают автоматическую конвертацию, её приходится делать вручную.
В некоторых случаях и в Java, например, при вычислении SHA256 хеша от строки, строку приходится переводить в байтовое представление конкретной кодировки (обычно UTF-8).
Моё же недовольство заключалось в близком расположении to_lower и UTF-8. Функция to_lower преобразовывает символы (wchar_t), а UTF-8 — это способ хранения этих символов.
В некоторых случаях и в Java, например, при вычислении SHA256 хеша от строки, строку приходится переводить в байтовое представление конкретной кодировки (обычно UTF-8).
Моё же недовольство заключалось в близком расположении to_lower и UTF-8. Функция to_lower преобразовывает символы (wchar_t), а UTF-8 — это способ хранения этих символов.
Ну почему же с игнорированием? Библиотечные функции (то же String.toLowerCase()) не игнорируют суррогатные пары, а корректно их обрабатывают.
Хочу заметить, что внутреннее представление строк в Java не специфицировано. Специфицирован тип char (это действительно UTF-16 символ). А строка — это просто строка, вас не должно волновать как она хранится. Нигде не сказано, что это набор char или что-то в этом духе. Более того, в Java-9 внутреннее представление строк действительно изменится (будет Latin-1, если все символы Latin-1 и UTF-16 в противном случае). Но опять же вы не должны на это закладываться.
Да, мне действительно все равно, какое там внутреннее представление.
А что касается суррогатных пар — в Java строки снаружи выглядят как массивы UTF-16 значений, а не массивы символов юникода. Если мы не хотим отказываться от корректной обработки суррогатных пар, то имеем проблему отсутствия произвольного посимвольного доступа при наличии символов с кодами выше 0x10000. Как следствие
— операции toLower и им подобные могут применяться только к строке целиком. Впрочем, и в C#, и в C++ нюансы работы со строками такие же.
А что касается суррогатных пар — в Java строки снаружи выглядят как массивы UTF-16 значений, а не массивы символов юникода. Если мы не хотим отказываться от корректной обработки суррогатных пар, то имеем проблему отсутствия произвольного посимвольного доступа при наличии символов с кодами выше 0x10000. Как следствие
— операции toLower и им подобные могут применяться только к строке целиком. Впрочем, и в C#, и в C++ нюансы работы со строками такие же.
Ещё раз — не выглядят строки как массивы. Строки выглядят как объекты с набором методов. Посимвольный доступ есть, хотя и может не такой удобный:
StringBuilder sb = new StringBuilder();
myString.codePoints().map(Character::toLowerCase).forEach(sb::appendCodePoint);Тут все суррогатные пары корректно обработаются. Нет случайного посимвольного доступа, но он обычно и не нужен.
Массив имеет индексатор [] и длину length, строка — charAt (в C# — индексатор []) и тоже длину length. Семантически — массив (произвольный доступ по индексу + длина). Но это моё субъективное мнение.
А так да: строка преобразовывается из внутреннего представления в UCS4, обрабатывается, затем преобразуется из UCS4 во внутреннее представление.
Точно такие же действия пришлось бы делать при обработке строк на C++: пробразовать строку из std::string (UTF8) или std::wstring (UTF16) в u32string или использовать потоки.
Отличие заключается в том, что в Java все эти преобразования делаются средствами стандартной библиотеки, а вот для C++ нужно искать сторонние библиотеки, либо писать велосипед.
Кстати, в .NET поддержка суррогатных пар значительно более слабая — нет методов для извлечения кодпоинтов кроме явного преобразования строки в формат UTF32 (int[]) string.toLower.
А так да: строка преобразовывается из внутреннего представления в UCS4, обрабатывается, затем преобразуется из UCS4 во внутреннее представление.
Точно такие же действия пришлось бы делать при обработке строк на C++: пробразовать строку из std::string (UTF8) или std::wstring (UTF16) в u32string или использовать потоки.
Отличие заключается в том, что в Java все эти преобразования делаются средствами стандартной библиотеки, а вот для C++ нужно искать сторонние библиотеки, либо писать велосипед.
Кстати, в .NET поддержка суррогатных пар значительно более слабая — нет методов для извлечения кодпоинтов кроме явного преобразования строки в формат UTF32 (int[]) string.toLower.
wstring это стринг из wchar_t, его размер — не фиксирован. Например, на ubuntu 14.04 x64
#include <stdio.h>
#include <wchar.h>
int main(int argc, char **argv){printf("%d\n",sizeof(wchar_t) );}
> ./a.out
4
зачем так (под виндой 16 бит, под линуксом 32) — хз.
#include <stdio.h>
#include <wchar.h>
int main(int argc, char **argv){printf("%d\n",sizeof(wchar_t) );}
> ./a.out
4
зачем так (под виндой 16 бит, под линуксом 32) — хз.
C++ сильно подводит среда сборки. В случае Java просто делаем git clone и начинаем работать, а в случае C++ нужно ещё вычислить, какие зависимости нужны проекту и подтянуть их через apt-get, а то и собрать. Почему, ну вот почему нельзя было встроить в среду сборки менеджер зависимостей, чтоб оно подтягивало и собирало их самостоятельно?!
Полностью солидарен с Alexey2005
Почему Java лучше:
1. Maven
2. IntelliJ IDEA
3. Интеграция Maven в IntelliJ IDEA
4. Дух опенсорса в проектах которые можно быстро клонировать, открыть в IDE, внести изменения, откомпилировать, запустить
Почему Java лучше:
1. Maven
2. IntelliJ IDEA
3. Интеграция Maven в IntelliJ IDEA
4. Дух опенсорса в проектах которые можно быстро клонировать, открыть в IDE, внести изменения, откомпилировать, запустить
Почему C++ лучше:
- Детерминизм удаления объектов
- Меньше проверок (например на выход за рамки массива)
- Исключения можно отключить
- Прямой доступ к SSE/AVX
- Очень зрелая (прям зрелая-зрелая) система OpenMP для декларативной параллелизации
- Можно использовать на GPU, Xeon Phi и т.д. (не без модификаций, но все же)
Знающие люди, поясните за модули в Java. Владимир Ситников предполагает, что это поможет избежать перекомпиляции кода при каждом запуске и позволит собирать более компактные jvm с урезанной стандартной библиотекой. Но ведь для этих целей модули вообще не нужны. Проверить изменения jar-ника можно по «inode + дата изменения + размер» или по хешу в крайнем случае. Модули ведь не дают больше гарантий, чем такая простая проверка? А что касается стандартной библиотеки, можно один большой jar разбить на 50 маленьких и при старте просто проверять наличие/отсутствие файлов по списку. Такая проверка, опять же, ничего не стоит. Получается, что потратили 5 лет (или не знаю, сколько, но много), усложнили жизнь некоторым разработчикам, но зачем?
Знающие люди, поясните за модули в Java
Речь про модули для C++. Чтобы вместо кучи .h, .cpp, .lib, makefile и прочей муры был один файл, который подключил как jar — и всё работает.
Во-первых — вы уверены, что все системы гарантируют наличие и изменение указанных данных? Более-менее гарантирующая проверка — вычисление хеша вряд ли даст экономию времени загрузки.
Во-вторых в java мире принято закладываться (спасибо maven-central!), что библиотека не будет изменена в пределах одной версии. Т.е. изменили библиотеку — измените версию. Нестабильные версии принято отличать по суффиксу -SNAPSHOT (они могут меняться без изменения версии).
По поводу «разбить один большой jar ...» — модульность специально разрабатывали, чтобы можно было удобно управлять этим самым «разбиением».
Т.е. если сильно захочется организовать поставку с jre — можно будет удобно управлять тем, что в неё войдёт.
PS имхо одна из ультимативных фич модульности — возможность скрывать от «пакостливых ручек» классы, которые не должны быть доступны. Т.е. сейчас, например, можно от package private классов отнаследоваться — достаточно создать в своём модуле такой же пакет, модульность должна порезать эту возможность.
Во-вторых в java мире принято закладываться (спасибо maven-central!), что библиотека не будет изменена в пределах одной версии. Т.е. изменили библиотеку — измените версию. Нестабильные версии принято отличать по суффиксу -SNAPSHOT (они могут меняться без изменения версии).
По поводу «разбить один большой jar ...» — модульность специально разрабатывали, чтобы можно было удобно управлять этим самым «разбиением».
Т.е. если сильно захочется организовать поставку с jre — можно будет удобно управлять тем, что в неё войдёт.
PS имхо одна из ультимативных фич модульности — возможность скрывать от «пакостливых ручек» классы, которые не должны быть доступны. Т.е. сейчас, например, можно от package private классов отнаследоваться — достаточно создать в своём модуле такой же пакет, модульность должна порезать эту возможность.
Сравним молоток и отвертку. И то и другое можно держать в руках. При желании отверткой можно забить гвоздь, а молотком если очень надо можно вкрутить саморез.
Ну вот примерно так же. Java медленнее супероптимизированного кода на плюсах. И никогда не сравнится с ним по скорости. Вот только никому не нужна супероптимизация на уровне всего проекта. Деление сдвигами, паддинг данных, прочие милые шалости. Обычно это нужно в редких сильнонагруженных отрезках кода.
Если критически важно быстродействие вы берете С и пишете что-то простое, но очень быстрое, если нужно навертеть спагетти из бизнес требований в стиле «здесь играем, здесь рыба, а вот этого клиента мы очень любим и даже на рыбе с ним играем», то вы берете инструмент, который позволит следующему за вами программисту не сойти с ума, разбираясь, что как и почему работает.
В итоге выходит, что из трех надо выбрать два:
— сложная бизнес логика,
— максимальное быстродействие,
— сохранение рассудка и желания жить к концу дня
Ну вот примерно так же. Java медленнее супероптимизированного кода на плюсах. И никогда не сравнится с ним по скорости. Вот только никому не нужна супероптимизация на уровне всего проекта. Деление сдвигами, паддинг данных, прочие милые шалости. Обычно это нужно в редких сильнонагруженных отрезках кода.
Если критически важно быстродействие вы берете С и пишете что-то простое, но очень быстрое, если нужно навертеть спагетти из бизнес требований в стиле «здесь играем, здесь рыба, а вот этого клиента мы очень любим и даже на рыбе с ним играем», то вы берете инструмент, который позволит следующему за вами программисту не сойти с ума, разбираясь, что как и почему работает.
В итоге выходит, что из трех надо выбрать два:
— сложная бизнес логика,
— максимальное быстродействие,
— сохранение рассудка и желания жить к концу дня
На самом деле, при наличии достаточного опыта, навертеть спагетти из бизнес требований можно и на С++. То есть, разработчик с достаточным количеством опыта, может писать любую сложную бизнес-логику и вообще делать все тот же массовый кровавый энтерпрайз. Опять же, хороший пример это Bloomberg, у которых вся платформа на С++. И ничего, живут как-то.
Разумеется, C и даже ассемблер — это не предел. Если действительно "критически важно быстродействие", нормальные люди берут VHDL и зашивают алгоритм в железо. Им смешно читать всякое "у меня супербыстро, потому что Си".
Андрей Паньгин: Редко, когда мы упираемся в производительность самой Java платформы. Обычно проблемы можно решить либо заменой алгоритма, либо масштабированием, то есть наращиванием железа. Чаще всего узким местом оказывается пропускная способность сети или дисковый ввод-вывод.Вот как раз масштабированием и изощренными алгоритмами и решаются проблемы с упором в производительность. А вы говорите — «редко»…
Мы выбираем JVM за те гарантии безопасности, что она нам даёт. В первую очередь — защиту от фатальных ошибок из-за неправильной работы с памятью. Искать проблемы, связанные с указателями или выходом за границы массива, в неуправляемом коде на порядок сложнее.В конечном итоге все упирается в квалификацию и дисциплину разработчиков. Java с её «гарантиями безопасности» позволяет достичь результата, используя менее квалифицированных программистов. Экономически это выгодно, конечно.
НЛО прилетело и опубликовало эту надпись здесь
Это практически одно и то же, но «вид сбоку».Java с её «гарантиями безопасности» позволяет достичь результата, используя менее квалифицированных программистовпри одной и той же квалификации в обоих языках выгоднее использовать язык, на котором делать продукт можно быстрее (включая выполнение всех требований)
К тому же, есть нюанс в определениях «одинаковая квалификация» и «выполнение всех требований». Исходя из нашего опыта, для написания безопасного (с точки зрения работы с памятью и другими ресурсами) кода на C++ в среднем нужна более высокая квалификация, чем для кода на Java.
Нет такого расового деления — разработчик java/разработчик c++.
На самом деле, такле разделение есть. У нас есть как те, так и другие, и мы не будем Java программистам ставить задачи с разработкой на C++, и наоборот. Да они и сами не возьмутся без крайней необходимости.
Что предпочтительнее: использование архитектурных особенностей машины вручную (С++), либо лучше положиться на динамические оптимизации JVM?… но не сильнее «ручной» настройки компилятора C++ :-) В лучшем для JIT случае — он так же силен (что вряд ли).
— Адаптивная компиляция и автоматическое управление памятью — как раз сильные стороны Java.
НЛО прилетело и опубликовало эту надпись здесь
Автоматическая оптимизация C++ компиляторов тоже «всегда работает» для всего проекта любого размера.
Возможность настроить (оптимизировать) компиляцию отдельных частей проекта (причем при необходимости — по-разному для разных частей) — это «бонус», которого нет в JIT.
Возможность настроить (оптимизировать) компиляцию отдельных частей проекта (причем при необходимости — по-разному для разных частей) — это «бонус», которого нет в JIT.
НЛО прилетело и опубликовало эту надпись здесь
Голословное утверждение. Не видел ни одного примера, чтобы на вычислительных задачах Java выиграла у релизной сборки С++. На реальных задачах — сеть, СУБД, это уже не так заметно.
Но если представить выставление параметра -O3 ручной оптимизацией, то утверждение становится верным =)
Но если представить выставление параметра -O3 ручной оптимизацией, то утверждение становится верным =)
На самом деле, очень бы хотелось увидеть, пример реальной вычислительной задачи где адекватно написанный С++ с -О2/-О3 проигрывает Java + JIT. Только задача должна быть действительно реальной, т.е. не тестирование аллокаций тысяч malloc(sizeof(int)) и тому подобное. И чтобы JIT не вырезал тестируемый код как неиспользованный.
Для ясности — я не то чтобы пытаюсь доказать что С++ быстрее Java, меня больше волнует, почему в С++ не впиливают JIT если он эффективней чем статические оптимизации.
Для ясности — я не то чтобы пытаюсь доказать что С++ быстрее Java, меня больше волнует, почему в С++ не впиливают JIT если он эффективней чем статические оптимизации.
Вы не о том спорите. Принципиальная разница между JIT и статической компиляцией — первая работает во время выполнения программы и потому сильно ограничена во времени. То, на что статический компилятор может потратить минуты, JIT должен успеть за секунду.
Особенно сильно разница видна в задачах обработки изображений:
1. Использование векторных инструкций, которое возможно в C++, но невозможно в Java. Современные компиляторы (как статические, так и некоторые JIT) умные и могут векторизовать простой код, но для сложных задач все равно приходится использовать платформо-зависимые intrinsics, которые дают ускорение в разы по сравнению с обычным кодом.
2. Прямой доступ к памяти без проверок и обёрток в C++ будет быстрее, чем в Java.
3. Статическая шаблонизация в C++ генерирует эффективный код, альтернатива в виде generics, разрешаемых в рантайме, имеет совершенно другое предназначение.
Небольшой момент: не знаю, как в C++, но из generics в C# таки можно выжать максимум производительности, если в качестве шаблонных параметров использовать только структуры — в этом случае JIT будет генерировать статические конструкции.
Особенно сильно разница видна в задачах обработки изображений:
1. Использование векторных инструкций, которое возможно в C++, но невозможно в Java. Современные компиляторы (как статические, так и некоторые JIT) умные и могут векторизовать простой код, но для сложных задач все равно приходится использовать платформо-зависимые intrinsics, которые дают ускорение в разы по сравнению с обычным кодом.
2. Прямой доступ к памяти без проверок и обёрток в C++ будет быстрее, чем в Java.
3. Статическая шаблонизация в C++ генерирует эффективный код, альтернатива в виде generics, разрешаемых в рантайме, имеет совершенно другое предназначение.
Небольшой момент: не знаю, как в C++, но из generics в C# таки можно выжать максимум производительности, если в качестве шаблонных параметров использовать только структуры — в этом случае JIT будет генерировать статические конструкции.
Ну я как бы про все это в курсе.
Еще бы добавил, что в С++ есть возможность создавать сложные value types (классы/структуры), что положительно отражается на кэше процессора.
Просто выше проскочило высказывание о том, что JIT дает более эффективный код чем статические оптимизации, и мне стало интересно.
Еще бы добавил, что в С++ есть возможность создавать сложные value types (классы/структуры), что положительно отражается на кэше процессора.
Просто выше проскочило высказывание о том, что JIT дает более эффективный код чем статические оптимизации, и мне стало интересно.
> Еще бы добавил, что в С++ есть возможность создавать сложные value types (классы/структуры), что положительно отражается на кэше процессора.
Если рассматривать JIT в целом, а не только к Java, то в .NET тоже есть возможность создавать value type. И работа с ними тоже получается эффективной.
Если рассматривать JIT в целом, а не только к Java, то в .NET тоже есть возможность создавать value type. И работа с ними тоже получается эффективной.
Вообще дает, в некоторых случаях. Разумеется, не на специально оптимизированном коде, а на коде общего назначения. Примеры:
- Java умеет оптимизировать код "оптимистично" — например, вместо проверки на null вставить SEH, который при вылете сгенерит правильный NullPointerException. И приведет к перекомпиляции этого куска кода уже с проверкой. Либо заменять виртуальный вызов на прямой, даже если в приложении существуют два разных класса-потомка.
- выделение памяти в джаве не требует синхронизации и работает намного быстрее сишных аллокаторов
В C++ можно минимизировать явное динамическое выделение памяти в пользу автоматического создания объектов на стеке, которое и работает намного быстрее любого аллокатора и без блокировок, и к тому же безопаснее. Например, нет указателей, которые нужно было бы проверять, ресурсы выделяются/удаляются в exception-safe режиме (RAII). Причем в C++ такой подход считается не специальной оптимизацией, а обычным рекоммендуемым подходом. Вряд ли JIT смог бы здесь что-либо улучшить.
Если вы про выделение памяти на стеке, то это далеко не универсальный подход… а) стековый объект нужно выделять явно б) компилятор (насколько я знаю) не умеет оптимизировать new в стековый объект и в) стековый объект имеет фиксированный скоуп и время жизни, что часто полезно, но ограничивает область применения
Я и не говорил об универсальности. Я сказал, что «можно минимизировать явное динамическое выделение памяти» (те самые new/delete или malloc/free).
a) наоборот: память под стековый объект выделяется неявно (автоматически), и так же неявно (автоматически) освобождается. Программисту ничего не нужно для этого делать (ни «new», ни «delete»), кроме соответствующего объявления переменной без указателей и ссылок, и (опционально) инициализации (если default инициализация не устраивает).
Вы, вероятно, «явное объявление переменной» назвали «явным выделением», однако это не одно и то же. Например, «явно объявленная» переменная типа «указатель» не означает, что соответствующий объект будет действительно выделен — вам в дополнение к объявлению еще и явное выделение нужно сделать (используя «new»), а затем и явное освобождение («delete»). А вот при «явном объявлении» стековой переменной (не указателя и не ссылки) память будет автоматически (==неявно) выделена и освобождена.
б) Этого и не требуется. «new»/«delete» — это тот самое явное динамическое управление ресурсами, использование которого следует минимизировать.
в) Да, время жизни ограничено текущим блоком. Но при грамотном использовании это существенно улучшает код сразу в нескольких направлениях: простота, безопасность, производительность. Причем до такой степени, что аргументы в пользу JIT типа «оптимизация проверки на null и быстрое выделение памяти без синхронизаций» становятся бессмысленными: в C++ можно с легкостью писать код, в котором эти улучшения «встроены генетически».
a) наоборот: память под стековый объект выделяется неявно (автоматически), и так же неявно (автоматически) освобождается. Программисту ничего не нужно для этого делать (ни «new», ни «delete»), кроме соответствующего объявления переменной без указателей и ссылок, и (опционально) инициализации (если default инициализация не устраивает).
Вы, вероятно, «явное объявление переменной» назвали «явным выделением», однако это не одно и то же. Например, «явно объявленная» переменная типа «указатель» не означает, что соответствующий объект будет действительно выделен — вам в дополнение к объявлению еще и явное выделение нужно сделать (используя «new»), а затем и явное освобождение («delete»). А вот при «явном объявлении» стековой переменной (не указателя и не ссылки) память будет автоматически (==неявно) выделена и освобождена.
б) Этого и не требуется. «new»/«delete» — это тот самое явное динамическое управление ресурсами, использование которого следует минимизировать.
в) Да, время жизни ограничено текущим блоком. Но при грамотном использовании это существенно улучшает код сразу в нескольких направлениях: простота, безопасность, производительность. Причем до такой степени, что аргументы в пользу JIT типа «оптимизация проверки на null и быстрое выделение памяти без синхронизаций» становятся бессмысленными: в C++ можно с легкостью писать код, в котором эти улучшения «встроены генетически».
Мы говорим об одном и том же. Локальные объекты — вещь полезная, но не панацея. К примеру, возьмите любую нетривиальную программу на С++ и замените глобальный operator new/delete на аллокатор им. Александреску (который с константным временем выделения-освобождения памяти) — разница в производительности будет существенной.
Никто и не говорит о панацее. Иначе new/delete выбросили бы из стандарта, чего точно никогда не произойдет.
Следует изначально стараться писать код с минимумом new/delete, либо подвергнуть его рефакторингу.
По-поводу замены всех операторов new: да, в реальной большой программе полностью сделать это не получится.
Однако даже минимизация их использования уже приведет к указанным бонусам (простота, безопасность, производительность).
Хотя время жизни «автоматических» переменных и ограничено текущим блоком, большинство таких блоков вложены в другие (причем многократно, вплоть до функции main на самом верху, где время их жизни равно времени работы программы). Стековая переменная, созданная на одном уровне, гарантированно существует для всех своих «потомков» (вложенных блоков или синхронно вызванных функций/методов), которые могут безопасно использовать её. Так что область использования таких переменных может быть намного больше, чем может показаться на первый взгляд.
замените глобальный operator new/delete на...Переопределение операторов new/delete ничего не даст, т.к. смысл в отказе от их явного использования. Так что это не сработает.
Следует изначально стараться писать код с минимумом new/delete, либо подвергнуть его рефакторингу.
По-поводу замены всех операторов new: да, в реальной большой программе полностью сделать это не получится.
Однако даже минимизация их использования уже приведет к указанным бонусам (простота, безопасность, производительность).
Хотя время жизни «автоматических» переменных и ограничено текущим блоком, большинство таких блоков вложены в другие (причем многократно, вплоть до функции main на самом верху, где время их жизни равно времени работы программы). Стековая переменная, созданная на одном уровне, гарантированно существует для всех своих «потомков» (вложенных блоков или синхронно вызванных функций/методов), которые могут безопасно использовать её. Так что область использования таких переменных может быть намного больше, чем может показаться на первый взгляд.
НЛО прилетело и опубликовало эту надпись здесь
>Вычислительные задачи это один из многих классов задач — в любом случае это написание кода на максимально близкого к asm.
Не совсем. Дело в том, что между случаем когда надо написать сверхоптимизированный код и случаем когда надо как можно быстрее написать прототип алгоритма, есть огромное количество промежуточных случаев когда нужен достаточно быстрый и при этом легко расширяемый/читаемый/абстрактный код. Ведь достаточно сложные алгоритмы, как и «обычный» код, так же нужно развивать, в них нужно фиксить баги и т.д. А в делать это с кодом который сильно заоптимизирован вручную довольно трудно.
Тут то на сцену выходит С++ с его zero cost abstraction.
И оптимизациями (разворачивание циклов, инлайн? девиртуализация, RVO, etc) занимается компилятор. И весьма неплохо.
Не совсем. Дело в том, что между случаем когда надо написать сверхоптимизированный код и случаем когда надо как можно быстрее написать прототип алгоритма, есть огромное количество промежуточных случаев когда нужен достаточно быстрый и при этом легко расширяемый/читаемый/абстрактный код. Ведь достаточно сложные алгоритмы, как и «обычный» код, так же нужно развивать, в них нужно фиксить баги и т.д. А в делать это с кодом который сильно заоптимизирован вручную довольно трудно.
Тут то на сцену выходит С++ с его zero cost abstraction.
И оптимизациями (разворачивание циклов, инлайн? девиртуализация, RVO, etc) занимается компилятор. И весьма неплохо.
Это только если делать программы для использования на широком спектре железа. Тогда да, JIT может динамически подстроить программу под тип и количество CPU и т.д. В принципе, это могло бы дать Java некоторое преимущество (хотя и это спорно) на, к примеру, зоопарке десктопов, если бы не чрезмерная требовательность к ресурсам.
Однако все опрошенные эксперты говорили об «интерпрайзе». Это значит — свои серверы, или по крайней мере — с исзвестной архитектурой. Статическая компиляция своего C++ кода с настройками под конкретную архитектуру сервера + перекомпиляция некоторых из используемых библиотк (делается 1 раз для каждой версии библиотеки) убивает указанное преимущество JIT.
Однако все опрошенные эксперты говорили об «интерпрайзе». Это значит — свои серверы, или по крайней мере — с исзвестной архитектурой. Статическая компиляция своего C++ кода с настройками под конкретную архитектуру сервера + перекомпиляция некоторых из используемых библиотк (делается 1 раз для каждой версии библиотеки) убивает указанное преимущество JIT.
Да, для серверов с известной архитектурой так и делается: оптимизации соответствуют тому процессору, который во всех нодах кластера. Плюс к этому, если сервера вообще ваши физически, вы можете в них втыкать всякие ускорители, и не важно взяли вы Xeon Phi или Tesla, это все равно программируется на С/С++.
Владимир Ситников: Если же говорить про C++, то, если библиотеку скомпилировали и библиотека выполняет виртуальный вызов, то всё, у пользователя нет шансов сделать вызов не виртуальным.О какой оптимизации речь? Производительности разработчика? Так вопрос был о рантайме.
В целом, один из самых действенных способов оптимизации — исключать лишние действия. Для того чтобы C++ библиотеки «видели» особенности их использования, программистам C++ приходится делать разнообразные приседания
Вообще-то, описанная как недостаток (да еще с точки зрения оптимизации в рантайме) особенность C++ дает прирост производительности по сравнению с Java. Причем как с точки зрения скорости начальной заргрузки программы, так и «рабочей» производительности.
[HFT в основном тяготеет к] использованию всяких FPGA, где и системный С присутствует…
Думаю, не следует переводить System C таким образом: это, всё-таки, имя собственное.
«И то, вот есть у меня строка, хочу ее побить на подстроки по пробелу — этого в стандартной библиотеке нет, то есть я должен брать стороннюю библиотеку (ну благо есть такая штука как Boost, там много полезного).»
Дальше не читал. Это как подключать для использования одной функции swap.
Дальше не читал. Это как подключать для использования одной функции swap.
>Прежде всего, я не считаю, что между этими языками существует какая-либо конкуренция. У каждого из них есть своя ниша, и они прекрасно сосуществуют вместе.
Мне кажется дальше можно уже не читать. Холивар на этом исчерпан.
Мне кажется дальше можно уже не читать. Холивар на этом исчерпан.
наивный спор: Java vs. C++. Хорошо спорить, когда знаешь, что от результата спора ничего не зависит.
я предлагаю другой спор: Java vs. Javascript. Здесь на карту ставится карьера Java-программистов. Почему? Потому что, начальнику отдела разработки в какой-то момент покажется более дешевым переписать весь бэкенд на Node.js. Потом ему приходит в голову другая мысль: давайте использовать AWS Lambdas для реализации микросервисной архитектуры. Вы все еще продолжаете спор? Возможно, вы даже выиграете, но работу вам придется сменить, потому что компании джава-программисты больше не нужны. Хорошо когда в компании 10-30 программистов, но что делать, если 200-1000? У простого программиста практически нет шансов достучаться до большого начальства — просто в один прекрасный день приходит письмо, что теперь компания использует javascript, и после этого можно только и спорить о том, что лучше C++ или Java на хабре.
Хорошо было бы, если спор Java vs. C++ был действительно актуальным…
я предлагаю другой спор: Java vs. Javascript. Здесь на карту ставится карьера Java-программистов. Почему? Потому что, начальнику отдела разработки в какой-то момент покажется более дешевым переписать весь бэкенд на Node.js. Потом ему приходит в голову другая мысль: давайте использовать AWS Lambdas для реализации микросервисной архитектуры. Вы все еще продолжаете спор? Возможно, вы даже выиграете, но работу вам придется сменить, потому что компании джава-программисты больше не нужны. Хорошо когда в компании 10-30 программистов, но что делать, если 200-1000? У простого программиста практически нет шансов достучаться до большого начальства — просто в один прекрасный день приходит письмо, что теперь компания использует javascript, и после этого можно только и спорить о том, что лучше C++ или Java на хабре.
Хорошо было бы, если спор Java vs. C++ был действительно актуальным…
"Потому что, начальнику отдела разработки в какой-то момент покажется более дешевым переписать весь бэкенд на Node.js. "
А потом разработчиков увезут в комнатки с белыми стенками.
То есть начальник отдела разработки ВДРУГ решает переписать все, что уже есть и работает, на другом языке, при этом попутно уволив проверенную годами команду из 1000 человек, и наняв одномоментно 1000 новых разработчиков? Он, либо безумен, либо работает на конкурентов.
Вы будете смеяться, но примерно так и есть. Я конечно утрировал «немного», но процесс примерно следующий: есть общий тренд, который развивается уже не один год, о переходе на подписочную модель. Чтобы реализовать такую модель и не прогореть, приложение нужно строить на принципах SaaS, Multitenancy и прочее. Дальше начинается чистая математика: открываем Amazon Calculator (я говорю Amazon, как один из наиболее популярных вариантов) и смотрим сколько стоит, например EC2 vs. Lamdba (если не нравится AWS, то к примеру Azure WebApps vs Azure Functions). Если финансовые гении компании после месяцев сидения за калькулятором приходятся к выводу о том, что лямбды намного дешевле, то дальше дело техники.
Выясняется, что js в лямбдах работает быстрее. Выясняется, что поддерживать js-лямбды проще, чем джавовские.
Добавляем в смесь еще кучу других модных тенденций (как насчет микросервисных архитектур или подхода Serverless) и получаем неутешительный вывод. Ваш сервер написанный на яве начинается быстренько дробиться в микросервисы и переписываться на Node.js.
Вой поднимается до небес, но поделать с этим уже ничего нельзя. Бизнес есть бизнес. А ваша карьера программиста продолжается уже в другой компании.
p.s. Никто не будет никого увольнять и нанимать заново. Переучивать — запросто.
Выясняется, что js в лямбдах работает быстрее. Выясняется, что поддерживать js-лямбды проще, чем джавовские.
Добавляем в смесь еще кучу других модных тенденций (как насчет микросервисных архитектур или подхода Serverless) и получаем неутешительный вывод. Ваш сервер написанный на яве начинается быстренько дробиться в микросервисы и переписываться на Node.js.
Вой поднимается до небес, но поделать с этим уже ничего нельзя. Бизнес есть бизнес. А ваша карьера программиста продолжается уже в другой компании.
p.s. Никто не будет никого увольнять и нанимать заново. Переучивать — запросто.
Перечитал комментарий пару раз, но так и не смог понять, в каком месте карьера Java-программистов «ставится на карту».
Это что, единственный работодатель в городе, где такая карьера возможна?
Это что, единственный работодатель в городе, где такая карьера возможна?
Наивный спор: Java vs. Javascript. Хорошо спорить, когда знаешь, что от результата спора ничего не зависит.
я предлагаю другой спор: Кофе против Чая. Здесь на карту ставится карьера Кофеманов. Почему? Потому что, начальнику отдела разработки в какой-то момент покажется более дешевым пересадить на хороший Чай. Потом ему приходит в голову другая мысль: давайте использовать «принцессу Канди» для реализации снабжения сотрудников кофеином. Вы все еще продолжаете спор? Возможно, вы даже выиграете, но работу вам придется сменить, потому что компании Кофеманы больше не нужны. Хорошо когда в компании 10-30 Кофеманов, но что делать, если 200-1000? У простого Кофемана практически нет шансов достучаться до большого начальства — просто в один прекрасный день приходит письмо, что теперь компания использует чай «Майский», и после этого можно только и спорить о том, что лучше Java vs. Javascript на хабре в комментах.
Хорошо было бы, если спор Java vs. Javascript был действительно актуальным…
я предлагаю другой спор: Кофе против Чая. Здесь на карту ставится карьера Кофеманов. Почему? Потому что, начальнику отдела разработки в какой-то момент покажется более дешевым пересадить на хороший Чай. Потом ему приходит в голову другая мысль: давайте использовать «принцессу Канди» для реализации снабжения сотрудников кофеином. Вы все еще продолжаете спор? Возможно, вы даже выиграете, но работу вам придется сменить, потому что компании Кофеманы больше не нужны. Хорошо когда в компании 10-30 Кофеманов, но что делать, если 200-1000? У простого Кофемана практически нет шансов достучаться до большого начальства — просто в один прекрасный день приходит письмо, что теперь компания использует чай «Майский», и после этого можно только и спорить о том, что лучше Java vs. Javascript на хабре в комментах.
Хорошо было бы, если спор Java vs. Javascript был действительно актуальным…
НЛО прилетело и опубликовало эту надпись здесь
C++ занимает свою нишу в трех основных дисциплинах (game dev, финансы и embedded)
mezastel, на самом деле есть еще одна ниша, где C++ обосновался довольно плотно. Это VFX (visual effects) софт, который включает в себя почти весь софт по пост-продакшен обработке изображений (в том числе и софт для трекинга элементов изображений, VR и прочее). Традиционно, программа на C++, GUI на QWidgets/QML, скриптинг на Python. Есть даже стандарт, который версии регламентирует (http://www.vfxplatform.com/). Так что еще и вся киноидустрия «сидит» на C++ :)
Эх, почитаю я когда-нибудь холивар «Scala vs Rust»?
Лет через 5 — 10, и то если сложится Rust поколение.
Надеюсь, что этого не случится, т.к. сравнивать Scala и Rust еще более глупо чем Java и C++, т.к. они вот уж совсем разные и для разного. Я имею ввиду не разумно сравнивать, исходя из задачи, а именно холиварить.
А что тут спорить? Однозначно rust и все :-)
Такой холивор не имеет смысла. Сказал пытается «впихнуть невпихуемое» так что одно и то же можно решить 4 разными способами. У Rust такой задачи не стоит — Раст даже не ООП в полноценном смысле, он не пытается городить функциональщину. Просто решает конкретную проблему — безопасности доступа к данным.
По сабжу, С++ вместе с Boost в достаточной степени кросс платформенный, т.е. разбираться в WinAPI или Posix API не обязательно (оставим это ценителям чистого С), не обязательно, но желательно иметь представление о «системколлах» и что за ними, в независимости от используемого языка (имхо, все разработчики С++ это знают, а Java программисты могут не волноваться).
Тот же Boost уже 100500 лет имеет умные указатели, и они давно уже в STL, но можно и руками рулить памятью, здесь управление памятью не может быть критерием оценки.
Отсутствие библиотек в С++ сомнительно, нет, их просто не до большого, а вот фреймворков действительно мало, но нельзя сказать что их нет совсем (ACE, TAO, CIAO), более того, солидный и ответственный производитель всегда зарелизит вам либы для своего продукта под С++, ведь этого требует индустрия, проверьте сами, от ИИ библиотек до брокеров сообщений, всегда найдется вариант.
При этом Java это EJB и Spring + попытки решить нерешаемые этим языком вопросы: Roo, Integration, Xtext, Xtend — это всё дич, кажется что myEclipse появилась от непреодолимого желания перестать писать на Java. Java как язык — это 1/3 XML ада минимум, а в JEE гораздо больше, метапрограммирование в Java нет, если сравнивать с магией прекомпила С++.
Boost — это либы уровня паттернов программирования, MSM, Proto, Spirit, сеть, указатели, контейнеры, — небольшие библиотеки, но очень мощные, да, ошибки компил_тайма на 20 экранов, ну и что.
С++ — язык с которого стоит начинать, если нет возможности/желания начинать с С, добиться просветления в ООП, АОП (например 10-Jul-2016 AspectC++ Release 2.1, т.ч. аспекты тоже не критерий оценки, они есть и в С++), ФП и метапрограммирование, дальше по ситуации, при этом начинать со стандарта 2003 года, и постепенно двигаться в 2017.
Java — язык на котором стоит пару лет поработать, что бы встретить Scala, перейти по самые помидоры в ФР, забыть о сайд-эффектах, адовом хмл, спагетти-коде, и твердо решить для себя, что после запланированного Хаскеля, с достигнувшим критической массы ФП-бэкграундом, стоит всё же вернуться в С++.
Если коротко, то сегодня без JVM невозможно представить индустрию, язык Java всё больше старается походить на Scala, но кода меньше не становиться. С++ крут, но сегодня, будучи студентов, не за что бы не начал изучение стандарта даже 2011, тяжело для глаз (м б сказывается привычка к Scala лаконичности).
И про Одноклассников, да, они весёлые ребята, переписать всё с диеза на Java — только у нас такое возможно. Напомню про hiphop, hack и весь этот hhvm, где «брюки действительно превращаются» в С++, и Хаскель фильтрует спам.
Тот же Boost уже 100500 лет имеет умные указатели, и они давно уже в STL, но можно и руками рулить памятью, здесь управление памятью не может быть критерием оценки.
Отсутствие библиотек в С++ сомнительно, нет, их просто не до большого, а вот фреймворков действительно мало, но нельзя сказать что их нет совсем (ACE, TAO, CIAO), более того, солидный и ответственный производитель всегда зарелизит вам либы для своего продукта под С++, ведь этого требует индустрия, проверьте сами, от ИИ библиотек до брокеров сообщений, всегда найдется вариант.
При этом Java это EJB и Spring + попытки решить нерешаемые этим языком вопросы: Roo, Integration, Xtext, Xtend — это всё дич, кажется что myEclipse появилась от непреодолимого желания перестать писать на Java. Java как язык — это 1/3 XML ада минимум, а в JEE гораздо больше, метапрограммирование в Java нет, если сравнивать с магией прекомпила С++.
Boost — это либы уровня паттернов программирования, MSM, Proto, Spirit, сеть, указатели, контейнеры, — небольшие библиотеки, но очень мощные, да, ошибки компил_тайма на 20 экранов, ну и что.
С++ — язык с которого стоит начинать, если нет возможности/желания начинать с С, добиться просветления в ООП, АОП (например 10-Jul-2016 AspectC++ Release 2.1, т.ч. аспекты тоже не критерий оценки, они есть и в С++), ФП и метапрограммирование, дальше по ситуации, при этом начинать со стандарта 2003 года, и постепенно двигаться в 2017.
Java — язык на котором стоит пару лет поработать, что бы встретить Scala, перейти по самые помидоры в ФР, забыть о сайд-эффектах, адовом хмл, спагетти-коде, и твердо решить для себя, что после запланированного Хаскеля, с достигнувшим критической массы ФП-бэкграундом, стоит всё же вернуться в С++.
Если коротко, то сегодня без JVM невозможно представить индустрию, язык Java всё больше старается походить на Scala, но кода меньше не становиться. С++ крут, но сегодня, будучи студентов, не за что бы не начал изучение стандарта даже 2011, тяжело для глаз (м б сказывается привычка к Scala лаконичности).
И про Одноклассников, да, они весёлые ребята, переписать всё с диеза на Java — только у нас такое возможно. Напомню про hiphop, hack и весь этот hhvm, где «брюки действительно превращаются» в С++, и Хаскель фильтрует спам.
резюмируя простыми словами, можно сказать, что с большей вероятностью, сильных разработчиков можно встретить в С++ и Scala, т.к эти языки гораздо многограннее и более навороченнее, чем Java, плюс желание Java программистов ощутимо меньше изучать Scala, чем желание C++ программистов изучать Java, и дело не в рынке, а скорее в регидности ;)
п.с. Одноклассники просьба себя не сдерживать и заминусовывать, только жаба быстрее не станет.
п.с. Одноклассники просьба себя не сдерживать и заминусовывать, только жаба быстрее не станет.
как вы наверное заметили, желание после Java изучать С++ не рассматривается в принципе;)))
А зря.
А почему зря?
Я почитал основы pure C попытался поискать что-то в интернете.
1. Открытые исходники — их очень много. Просто скомпилировать их — это иной раз серьёзный квест.
2. Решения. Очень много ошибок, как мне показалось.
Сейчас читаю java (основы). Очень редко для избранного софта (обычно рф гос софта) одна проблема, надо конкретную версию java. И то, надо ли?
ps
Хочу уйти с fpc, пока плюсов в этих языках не увидел.
Я почитал основы pure C попытался поискать что-то в интернете.
1. Открытые исходники — их очень много. Просто скомпилировать их — это иной раз серьёзный квест.
2. Решения. Очень много ошибок, как мне показалось.
Сейчас читаю java (основы). Очень редко для избранного софта (обычно рф гос софта) одна проблема, надо конкретную версию java. И то, надо ли?
ps
Хочу уйти с fpc, пока плюсов в этих языках не увидел.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
Let the Holy War begin: Java vs С++