Дык я и не обижаюсь, и тем более не замыкаюсь, а отвечаю по мере возможности в свободное время :)
Кому-то будет интересно, кому-то нет, это нормально.
Код постараюсь выложить на гитхаб если он станет для Вас лучше от этого :)
А судить о качестве статьи по тому где выложен код, это как-то… странно :)
Мда… Мне ещё не приходилось писать столько отрицательных комментариев, к статье с вроде как правильной изначальной идеей — такого уникально низкого уровня реализации я давно не видел.
Ну это Ваша, абсолютно субъективная точка зрения совершенно ничем не подкрепленная. На это можно ответить только что-нибудь типа «я давно не видел комментария с таким высоким уровнем предвзятости и фанатизма».
Для начала сразу же повеселила фраза
Ну ладно хоть развеселило, но по мне так это грустно.
Во-первых, JVM бывают разные, есть очень маленькие.
Во-вторых, в JVM логика программы четко отделена от рантайма языка.
В-третьих, JVM портирован почти везде, так что можно считать его частью системы.
Раз уж это моя статья позвольте мне и решать кого записывать в перспективные. Напишите свою — с удовольствием почитаю.
На фоне предыдущего пункта меня сильно поразило наличие в тестирование C++/Qt, т.к. как раз Qt и является примером очень жирной библиотеки — тут было явно что-то не то.
На мой взгляд, красота и удобство Qt API в сравнении с убогой std в разы перевешивают возможные потери производительности.
Но когда я увидел размер программы на Qt в 37 КБ, то всё стало на свои слова — автор похоже ещё и не особо разбирается в разнице между статической и динамической линковкой…
А мне кажется что Вы слегка забываетесь и переходите на личности. Как я уже писал в Qt я использовал дефолтный профиль Release ничего не меняя. И Qt, естественно, использовал динамическую линковку, это нормально и правильно.
Так же слегка шокировали слова «обычные язык, без откровений» по отношению к Scala. И это про язык, который принёс полноценное функциональное программирование и метапрограммирование в мир JVM.
За функциональное программирование в статье ничего не было. Мне как-то Haskell-а вполне хватает.
Собственно как и ожидалось, там был классический «java стиль»
Да нет там никакого «Java стиля» обычный Qt-шный код.
Если же решить эту простейшую задачку на нормальном современном C++ (и для начала это будет Boost, а не Qt),
Думаю что не стоит выносить это в заголовок, это будет понятно из контекста по мере прочтения.
Но все равно спасибо за Ваше мнение, я, если честно, тоже колебался добавить O3 или нет, примерно с такими же аргументами как в нашем диалоге :)
Думаю тут дело в том, что выбор языка программирования это вопрос достаточно интимный, сродни выбору жены :), а при сравнении всем не угодишь, вот последователи разных языковых школ и размахались «минусовками». Ваш, коммент тоже, наверное, заминусуют :)
Хм… как-то не доводилось сталкиваться с их медленностью, это надо очень постараться чтобы так накосорезить в коде чтения из файла в стандартной проверенной-перепроверенной либе.
Спасибо! По мне так про бенчмаки всегда интересно почитать тем более когда за тебя кто-то уже это все проделал :)
Ну а профессиональные (и адекватные :) ) комментарии к коду только приветствуются.
Вполне возможно, что есть небольшие расхождения, код писался в урывками в свободное от работы время, но если вы убедите меня что это может существенно повлиять на перформанс я постараюсь исправить и обновить результаты.
Вообще, я вроде старался активно использовать константные ссылки где можно. Возможности по перемещению из C++11, действительно не использовал.
Да нет, размеры классов я выложил просто для информации, чтобы, можно было сравнить их, например, с размерами классов в чистой Java и посмотреть насколько толста прослойка нагенеренная Scala или Kotlin компилятором. С Rust-ом, конечно, сравнивать не будем, там не получится отделить мух от котлет, сколько Кб на логику ушло, сколько на сам язык.
Во-первых, вы как-то забыли упомянуть арифметику с плавающей точкой и работу со строками.
Во-вторых, для языков с JVM подсистема ввода-вывода особой роли как раз не играет, т.к. используется из Java, а результаты тем не менее существенно различаются.
Так что здесь, всего лишь, сравниваются производительность языков на JVM и тесты на мой, естественно, субъективный взгляд вполне адекватные и показательные :)
Кому нужны другие тесты могут проделать эту работу самостоятельно и поделиться результатом, с большим интересом почитаю :)
P.S. на гитхаб выложу на досуге, может и правда блох наловим в коде :)
Я рад что работа JIT подсистемы для вас очевидна. Но мне не хотелось «думать» за JVM, как она там будет оптимизировать в рантайме, меня не особо тревожит, это ее дело. Кстати, JIT компилятор тоже написан на C/C++ и настройки компилятора с которыми он был построен напрямую влияют на его производительность так что с корректностью здесь я не вижу никаких проблем.
Повторюсь, компилятор настроен профилем Release — точка. И у меня нет желания прогонять его с десятками разных ключей для GCC или Microsoft Compiler-а и выбирать лучший вариант для C++. Как настроили разработчики — так и поехало.
Предлагаю завершить на этом дискуссию, если вам интересно с O3 — исходники в вашем распоряжении, проверяйте, делитесь результатами.
Я не имел ввиду классы которые считают с произвольной точностью типа Decimal, пусть они себе живут отдельно, но написать класс заменяющий float и double вполне здравая идея и, например, в Ceylon так и сделали: ceylon-lang.org/documentation/1.3/tour/language-module/#numeric_types
Насчет эффективности, я специально запрофилировал getDistance в моих тестах, где происходят самые интенсивные вычисления с плавающей точкой и Ceylon показал результат лучше чем Kotlin, но хуже чем Java.
Мое мнение что если такой класс реализован достаточно эффективно в 99% случаев можно не парится и использовать его. Но, конечно, если на финальной стадии при профилировании обнаруживаются узкие места, тогда уже есть смысл начать что-то оптимизировать.
Сравнивалось не C++ с JVM, а производительность разных языков на JVM. То что JVM работает нормально и на нем можно писать все что угодно у меня сомнений не вызывало.
Хорошо, не будем спорить о частностях здесь. В контексте статьи, я не «ищу производительность», я сравниваю производительность языков в их дефолтной конфигурации. Для Qt это Release.
Взять хотя бы "-march=native -mtune=native" — это уже нарушение одинаковых условий для всех, ведь JVM не был скомпилирован конкретно для моей машины.
Давайте попробуем, но, на мой взгляд, выбирая профиль Release я уже и так явно выразил свои намерения и «подписался» под производительностью. А если пользователю после этого нужно все-таки лезть в настройки и прописывать какие-то дополнительные ключи, это недоработка среды/билдсистемы.
Я вообще старался не пользоваться какими-то специфичными трюками конкретного языка чтобы не создавать ему преференций.
Просто в JVM ввод-вывод лучше оптимизирован чем в Qt, вот и все — никаких чудес.
P.S. ты давай там завязывай с тапкапи общаться, так и до дурки недалеко :)
Кому-то будет интересно, кому-то нет, это нормально.
Код постараюсь выложить на гитхаб если он станет для Вас лучше от этого :)
А судить о качестве статьи по тому где выложен код, это как-то… странно :)
Ну это Ваша, абсолютно субъективная точка зрения совершенно ничем не подкрепленная. На это можно ответить только что-нибудь типа «я давно не видел комментария с таким высоким уровнем предвзятости и фанатизма».
Ну ладно хоть развеселило, но по мне так это грустно.
Во-первых, JVM бывают разные, есть очень маленькие.
Во-вторых, в JVM логика программы четко отделена от рантайма языка.
В-третьих, JVM портирован почти везде, так что можно считать его частью системы.
Раз уж это моя статья позвольте мне и решать кого записывать в перспективные. Напишите свою — с удовольствием почитаю.
На мой взгляд, красота и удобство Qt API в сравнении с убогой std в разы перевешивают возможные потери производительности.
А мне кажется что Вы слегка забываетесь и переходите на личности. Как я уже писал в Qt я использовал дефолтный профиль Release ничего не меняя. И Qt, естественно, использовал динамическую линковку, это нормально и правильно.
За функциональное программирование в статье ничего не было. Мне как-то Haskell-а вполне хватает.
Да нет там никакого «Java стиля» обычный Qt-шный код.
Код в студию, пожалуйста, только не в С-style.
Но все равно спасибо за Ваше мнение, я, если честно, тоже колебался добавить O3 или нет, примерно с такими же аргументами как в нашем диалоге :)
Думаю тут дело в том, что выбор языка программирования это вопрос достаточно интимный, сродни выбору жены :), а при сравнении всем не угодишь, вот последователи разных языковых школ и размахались «минусовками». Ваш, коммент тоже, наверное, заминусуют :)
Ну а профессиональные (и адекватные :) ) комментарии к коду только приветствуются.
Вообще, я вроде старался активно использовать константные ссылки где можно. Возможности по перемещению из C++11, действительно не использовал.
Во-вторых, для языков с JVM подсистема ввода-вывода особой роли как раз не играет, т.к. используется из Java, а результаты тем не менее существенно различаются.
Так что здесь, всего лишь, сравниваются производительность языков на JVM и тесты на мой, естественно, субъективный взгляд вполне адекватные и показательные :)
Кому нужны другие тесты могут проделать эту работу самостоятельно и поделиться результатом, с большим интересом почитаю :)
P.S. на гитхаб выложу на досуге, может и правда блох наловим в коде :)
Повторюсь, компилятор настроен профилем Release — точка. И у меня нет желания прогонять его с десятками разных ключей для GCC или Microsoft Compiler-а и выбирать лучший вариант для C++. Как настроили разработчики — так и поехало.
Предлагаю завершить на этом дискуссию, если вам интересно с O3 — исходники в вашем распоряжении, проверяйте, делитесь результатами.
Насчет эффективности, я специально запрофилировал getDistance в моих тестах, где происходят самые интенсивные вычисления с плавающей точкой и Ceylon показал результат лучше чем Kotlin, но хуже чем Java.
Мое мнение что если такой класс реализован достаточно эффективно в 99% случаев можно не парится и использовать его. Но, конечно, если на финальной стадии при профилировании обнаруживаются узкие места, тогда уже есть смысл начать что-то оптимизировать.
Взять хотя бы "-march=native -mtune=native" — это уже нарушение одинаковых условий для всех, ведь JVM не был скомпилирован конкретно для моей машины.
Я вообще старался не пользоваться какими-то специфичными трюками конкретного языка чтобы не создавать ему преференций.
Вот исходники: drive.google.com/open?id=1N3sEsw4MZ33GI-PPQOw_vocahGdjg9bq
Вот тулза mp2dcf (набросал на Kotlin за час :) ), которая конвертирует карты в «польском» формате в DCF: drive.google.com/open?id=12SlixUmpnrKH5Eh8k69m_T1tmWCVy6Ko
Карты можно скачать например тут: navitel.osm.rambler.ru
Я успел попробовать на Италии: navitel.osm.rambler.ru/?country=Italy