памяти. IO Операции (сетевые) что в Java что в С++ потребляют фактически одинаково CPU. Что С++, что Java это обертка над системными вызовами IO операций. Сравнивать производительность имеет смысл вообще только для каких то нагруженных вычислений. А когда 99% работы - это IO операции (вызовы OS), то выгоды в C++ нет.
А SAX парсер java или xerces C++ для 10Кб XML это неуловимая разница (даже если она есть).
Переписанный обработчик с C++ под java. TCP/IP listener (не http), TCP/IP клиент и коннект к БД. XML поверх TCP/IP Фактически навороченный маршрутизатор.
на бою работают обе версии (на разных комплексах, но на одной физически машинке). Так вот.. в быстродействии разницы нет. Что там что там в районе 20..30 ms на обработку через БД и маршрутизацию. Да. ресурсов C++ вариант потребляет меньше. но не принципиально. где то на 70-80% (процент большой большие, но от общей памяти сервера разница не значительная). Но насколько удобнее и проще:
вносить изменения и новый функционал.
Не надо выпускать много дистрибутивов под каждые аппаратные платформы (и тестировать их)
Не надо ставить драйвер БД, поскольку Jdbc это thin драйвер. 4.логирование апачевским log4j2 в централизированое хранилище (не находил для C++ точного аналога)
Понадобился асихронный канал для маршрутизации - нет проблем. Вот клиент для kafka (java). А для С++ куда ни сунешься - попробуй найди библиотеку.
Я последние лет 5 пишу исключительно "перекладыватели байтов из одного протокола в другой и в БД". В общем то все задачи процессинга платежей и переводы денег к этому и сводятся.
Отдушина - хоббийные программки. Хотя.. то же укладывние видеопотока в TCP/IP - это то же перекладывание байтиков/битиков.
Но перекладывать байтики и битики, для типичных моих задач на работе, не изобретая велосипед проще на Java (+python +js) Попробуй найди нормальную библиотеку реализации HTTP сервера, или обработки Json, которая "широко известна и используется в широких кругах", а не "широко известна в узких кругах С++". А Postgre/Oracle клиент (полный как jdbc, а не OCI драйвер) под C++? а клиент kafka под C++?
Коллеги из отдела разработки ПО для платежных терминалов постепенно переходят на Java (android). Все современные терминалы идут в основном уже "не голый C++/C" без OS, а под Android.
Я помню, сколько стоило перетащить ПО с одной платформы (POS терминалы) на другую (другой проц) с особенностями адресации и сегментации.
Конечно для какого ни будь контроллера c ядром Cortex-M3 иногда даже на C/C++ места впритык.
Но я все равно не хотел бы для пром. комплексов (unix/linux) где нет жестких ограничений по ресурсам писать на С++. Просто могу сравнить сколько на разработку развитие и поддержку одних и тех же по функционалу программ уходит, если писать на С++ и на Java.
Зачастую проще переписать старую программу сделанную на С++ под Java, чем продолжать развитие этой старой программы на С++.
Собственно, это часто приходится делать в последние годы. Дешевле переписать и внести новый функционал уже в переписанное, чем развивать старое.
И зачастую это ПО я сам лет 10 назад писал. Т.е. проблема не в том, что бы вникнуть как это старое работает. А просто активно не хочется продолжать его развивать на С++. Займет больше времени и передать некому (найти С++ разработчика с опытом - проблема)
Так что, для общих задач (перекладывания байтиков в протоколах типа json и работа с БД) пусть мазохисты используют С++. У меня есть возможность сравнить и для меня выбор очевиден.
Я 15 лет писал на С++ для разных "железных" устройств (типа Verifone терминалов/PINPAD), unix систем (демоны и пр.) и сервисы/прикладные программы Windows. Так что, не теоретически знаком с этим.
90% проблем (core dump) это последствие порчи стека/памяти иногда за несколько минут до фактического возникновения exception. И не надо мне говорить про безопасные vector и прочее. В не учебных и сложных программах всегда найдется место где что то будет не учтено не смотря на все авто ptr, вектора, обработчики исключений и прочие обкладки.
А когда в стрессовых условиях начинаешь разбираться почему упало и как это исправить - это запоминается надолго. Работает на одной платформе (sparc, например) и нерегулярно (пару раз в неделю) падает на другой (x86) - типичный пример таких разборок.
Так что, у меня есть с чем сравнивать. На Java (последние лет 7 на Java и С++ с плавным смещение в строну кроссплатформенных программ на Java) мне гораздо комфортнее. И время поиска проблем гораздо меньше.
А спорить с фанатиками С++, которые ничего другое и не пробовали (да и на С++ максимум год) - дурное дело. Их лучше обходить большим кругом.
Не указан самый главный навык С/С++. Умение работать с core dump полученный с боевой системы в условиях стресса и криков "все пропало! все стоит! когда же будет почиииняно!?".
P.S. Как мне хорошо, что я перешел давно на Java и как мило разбирать стек ошибок Java в логе.
Чего вы так жестоко. Протереть стекла и попинать колеса - это первое что нужно сделать, если машина не заводится.
можно еще в бубен постучать.
И только если вообще все не помогает, то можно включить логирование и посмотреть первопричину проблемы. Но это же не спортивно! Методом тыка же гораздо интереснее искать.
но тема алгебраических свойств integer'а и float'а, действительно, не часто освещается в литературе и интернетах, однако эти знания углубляют понимание реализации компьютерной арифметики и применимы на практике.
А Вы не задумывались почему "не часто"?
Вот когда то давно, учил и теорию групп в рамках вышки и одновременно теорию выч машин (типичная тема курсовиков - создание ALU). И как то никто из преподавателей не пытался натянуть сову на глобус.
Вы точно уверены в необходимости объяснения такой простой вещи как двоичная арифметика и представление чисел в "дополнительной кодировке" через призму удобной именно Вам "совы" (терминологии и мат аппарата)?
Особенно, с учетом того, что Вас сподвигло на это ошибка в использовании (понимании) целочисленной арифметики (конкретной реализации архитектуры, кстати. Хоть и наиболее типичной сейчас).
Извините. Но что то вспомнился анекдот, с уроком в средней школе по площади треугольника и совету учительницы поменять пределы интегрирования на вопрос ученика, почему площадь у него отрицательная в расчетах.
всегда всплывет то что было. Многие с машин сняли наклейки (кроме самых упертых) после мобилизации.. да и царапать краску/колеса прокалывать стали. Но никто не забыт... То же и с этим. Специально не буду выяснять кто там чем занимался до. Но если узнаю.. я не злопамятный. просто память хорошая.
А исхожу из того, что каждый должен на себя брать персональную ответственность за то, что он делает. И говорил про отношение к совершенно конкретным людям, которые занимаются чем то, что лично мне категорически не нравится. Будь то блокировками сайтов, которые кто то назвал "не правдивыми" или тем, что сейчас обсуждать нельзя (почему то за не любовь к рыбе можно и сесть). Эта конкретная личность это делает, прочем без принуждения - я к нему отношусь как считаю нужным. И пофиг, что по его мнению "третья мировая - победим играя".
Фразу "виноват РНК" я не понимаю. Кто такой РНК? это не личность. Это набор людей, которые там работают. А как показывает история отмазка "все так.. мне приказали.. я просто делал свою работу" не работает.
А Вы не передергивайте. Я говорил конкретно по Росскомпозор который в России исполняет задания по политической цензуре на 99%. С теми людьми, которые еще где либо там блокировали по политическим мотивам в других странах я то же если пересекусь, то не постесняюсь им "фу" сказать.
И минус, кстати, не я Вам поставил... что характерно
Вы знаете, да. Всем уволится. Я например никогда не буду работать вместе с человеком рядом, если узнаю что он работал на такую структуру. Да просто не возьму его в свой отдел. А если будет работать в соседнем, то широко распространю информацию чем он занимался "на благо народа".
А ваши рассуждения - это как оправдывать помошника палача "а чо..он сам то головы не рубил. только топор подносил и пр. Нормальная работа без крови".
памяти.
IO Операции (сетевые) что в Java что в С++ потребляют фактически одинаково CPU. Что С++, что Java это обертка над системными вызовами IO операций. Сравнивать производительность имеет смысл вообще только для каких то нагруженных вычислений. А когда 99% работы - это IO операции (вызовы OS), то выгоды в C++ нет.
А SAX парсер java или xerces C++ для 10Кб XML это неуловимая разница (даже если она есть).
Переписанный обработчик с C++ под java.
TCP/IP listener (не http), TCP/IP клиент и коннект к БД. XML поверх TCP/IP
Фактически навороченный маршрутизатор.
на бою работают обе версии (на разных комплексах, но на одной физически машинке).
Так вот.. в быстродействии разницы нет. Что там что там в районе 20..30 ms на обработку через БД и маршрутизацию.
Да. ресурсов C++ вариант потребляет меньше. но не принципиально. где то на 70-80% (процент большой большие, но от общей памяти сервера разница не значительная).
Но насколько удобнее и проще:
вносить изменения и новый функционал.
Не надо выпускать много дистрибутивов под каждые аппаратные платформы (и тестировать их)
Не надо ставить драйвер БД, поскольку Jdbc это thin драйвер. 4.логирование апачевским log4j2 в централизированое хранилище (не находил для C++ точного аналога)
Понадобился асихронный канал для маршрутизации - нет проблем. Вот клиент для kafka (java). А для С++ куда ни сунешься - попробуй найди библиотеку.
Я последние лет 5 пишу исключительно "перекладыватели байтов из одного протокола в другой и в БД". В общем то все задачи процессинга платежей и переводы денег к этому и сводятся.
Отдушина - хоббийные программки. Хотя.. то же укладывние видеопотока в TCP/IP - это то же перекладывание байтиков/битиков.
Но перекладывать байтики и битики, для типичных моих задач на работе, не изобретая велосипед проще на Java (+python +js)
Попробуй найди нормальную библиотеку реализации HTTP сервера, или обработки Json, которая "широко известна и используется в широких кругах", а не "широко известна в узких кругах С++". А Postgre/Oracle клиент (полный как jdbc, а не OCI драйвер) под C++? а клиент kafka под C++?
Коллеги из отдела разработки ПО для платежных терминалов постепенно переходят на Java (android). Все современные терминалы идут в основном уже "не голый C++/C" без OS, а под Android.
Я помню, сколько стоило перетащить ПО с одной платформы (POS терминалы) на другую (другой проц) с особенностями адресации и сегментации.
Конечно для какого ни будь контроллера c ядром Cortex-M3 иногда даже на C/C++ места впритык.
Но я все равно не хотел бы для пром. комплексов (unix/linux) где нет жестких ограничений по ресурсам писать на С++. Просто могу сравнить сколько на разработку развитие и поддержку одних и тех же по функционалу программ уходит, если писать на С++ и на Java.
Зачастую проще переписать старую программу сделанную на С++ под Java, чем продолжать развитие этой старой программы на С++.
Собственно, это часто приходится делать в последние годы. Дешевле переписать и внести новый функционал уже в переписанное, чем развивать старое.
И зачастую это ПО я сам лет 10 назад писал. Т.е. проблема не в том, что бы вникнуть как это старое работает. А просто активно не хочется продолжать его развивать на С++.
Займет больше времени и передать некому (найти С++ разработчика с опытом - проблема)
Так что, для общих задач (перекладывания байтиков в протоколах типа json и работа с БД) пусть мазохисты используют С++. У меня есть возможность сравнить и для меня выбор очевиден.
Какой "тонкий" и "закамуфлированный" наезд. Про руки из жопы.
Не делает вам чести.
Скорее говорит о вашей склонности к склочности и пр.
Я 15 лет писал на С++ для разных "железных" устройств (типа Verifone терминалов/PINPAD), unix систем (демоны и пр.) и сервисы/прикладные программы Windows.
Так что, не теоретически знаком с этим.
90% проблем (core dump) это последствие порчи стека/памяти иногда за несколько минут до фактического возникновения exception. И не надо мне говорить про безопасные vector и прочее. В не учебных и сложных программах всегда найдется место где что то будет не учтено не смотря на все авто ptr, вектора, обработчики исключений и прочие обкладки.
А когда в стрессовых условиях начинаешь разбираться почему упало и как это исправить - это запоминается надолго.
Работает на одной платформе (sparc, например) и нерегулярно (пару раз в неделю) падает на другой (x86) - типичный пример таких разборок.
Так что, у меня есть с чем сравнивать. На Java (последние лет 7 на Java и С++ с плавным смещение в строну кроссплатформенных программ на Java) мне гораздо комфортнее. И время поиска проблем гораздо меньше.
А спорить с фанатиками С++, которые ничего другое и не пробовали (да и на С++ максимум год) - дурное дело. Их лучше обходить большим кругом.
Не указан самый главный навык С/С++. Умение работать с core dump полученный с боевой системы в условиях стресса и криков "все пропало! все стоит! когда же будет почиииняно!?".
P.S. Как мне хорошо, что я перешел давно на Java и как мило разбирать стек ошибок Java в логе.
Чего вы так жестоко. Протереть стекла и попинать колеса - это первое что нужно сделать, если машина не заводится.
можно еще в бубен постучать.
И только если вообще все не помогает, то можно включить логирование и посмотреть первопричину проблемы. Но это же не спортивно! Методом тыка же гораздо интереснее искать.
А Вы не задумывались почему "не часто"?
Вот когда то давно, учил и теорию групп в рамках вышки и одновременно теорию выч машин (типичная тема курсовиков - создание ALU). И как то никто из преподавателей не пытался натянуть сову на глобус.
Вы точно уверены в необходимости объяснения такой простой вещи как двоичная арифметика и представление чисел в "дополнительной кодировке" через призму удобной именно Вам "совы" (терминологии и мат аппарата)?
Особенно, с учетом того, что Вас сподвигло на это ошибка в использовании (понимании) целочисленной арифметики (конкретной реализации архитектуры, кстати. Хоть и наиболее типичной сейчас).
Извините. Но что то вспомнился анекдот, с уроком в средней школе по площади треугольника и совету учительницы поменять пределы интегрирования на вопрос ученика, почему площадь у него отрицательная в расчетах.
Получается, что теперь нужно говорить, например, не "ЕР - это бренд", а "ЕР - это клеймо". И если что, ссылаться можно на закон?
не товариш майор. перелогиньтесь и идите на х.й
Я ничего не призываю. За призывание у нас до 5 лет. За публичную дискредитацию.
а то и теракт подтянут.
всегда всплывет то что было.
Многие с машин сняли наклейки (кроме самых упертых) после мобилизации.. да и царапать краску/колеса прокалывать стали. Но никто не забыт...
То же и с этим. Специально не буду выяснять кто там чем занимался до. Но если узнаю.. я не злопамятный. просто память хорошая.
Бог простит.. (хотя я скорее агностик)
А исхожу из того, что каждый должен на себя брать персональную ответственность за то, что он делает. И говорил про отношение к совершенно конкретным людям, которые занимаются чем то, что лично мне категорически не нравится. Будь то блокировками сайтов, которые кто то назвал "не правдивыми" или тем, что сейчас обсуждать нельзя (почему то за не любовь к рыбе можно и сесть).
Эта конкретная личность это делает, прочем без принуждения - я к нему отношусь как считаю нужным. И пофиг, что по его мнению "третья мировая - победим играя".
Фразу "виноват РНК" я не понимаю. Кто такой РНК? это не личность. Это набор людей, которые там работают.
А как показывает история отмазка "все так.. мне приказали.. я просто делал свою работу" не работает.
А отдачи от защиты от утечек персональных данных я как то не наблюдаю.
Все эти организации откуда утекли данные - все имели формальные лицензии.
Почему так все любят передергивать. Это все РАЗНЫЕ подразделения.
Вы еще упомяните уборщиц и водителей.
Да ну! Роскомнадзор следит за исполнением? А можно ссылочки на результаты выполнения их обязанностей? именно результаты.
Про утечки - знаю. Про весьма формальные проверки, которые "оценивают" (по бумажкам) то же знаю.
А Вы не передергивайте. Я говорил конкретно по Росскомпозор который в России исполняет задания по политической цензуре на 99%. С теми людьми, которые еще где либо там блокировали по политическим мотивам в других странах я то же если пересекусь, то не постесняюсь им "фу" сказать.
И минус, кстати, не я Вам поставил... что характерно
Вы знаете, да. Всем уволится.
Я например никогда не буду работать вместе с человеком рядом, если узнаю что он работал на такую структуру. Да просто не возьму его в свой отдел. А если будет работать в соседнем, то широко распространю информацию чем он занимался "на благо народа".
А ваши рассуждения - это как оправдывать помошника палача "а чо..он сам то головы не рубил. только топор подносил и пр. Нормальная работа без крови".