Я, конечно, дико извиняюсь, но по-моему снова «порожняк гоняем». Бла-бла-бла…
Я то как раз прекрасно понимаю что я измеряю и как, если ты чего-то не понял из статьи — спрашивай, начнем нагружать тебе мозг :)
Если хочешь предложить что-то конкретное, предлагай — рассмотрим.
P.S. с теми кто обращается на Вы я тоже на Вы, с теми кто на ты, тоже на ты, так что без обид :)
Меньше получаемого в Rust/D/Nim исполняемого файла под той же платформой? )
Исполняемый файл будет больше чем jar, но зато в нем будут все «кишки» языка :) если прибавить рантайм Java то он будет весить больше.
Вам самому-то не надоело это муслоить? :) Вроде бы очевидные вещи.
Совершенно не хочется пересказывать ту часть статьи другими словами — кратко «жирные» бинари на мой взгляд это не эстетично, думаю тут есть простор для оптимизации, не более того. А вышеупомянутые языки отсеялись по многим другим факторам, в частности:
Похоже кто-то тут путает кроссплатформенность (имеется не только у JVM, а много где, включая и Rust/D/Nim) и предустановленный в данной ОС рантайм.
А похоже кто-то очень любит поумничать :) ну да ладно все мы тут не без греха :)
Думаю что JVM портирован на большее количество платформ чем тот же Nim и Rust — это кроссплатформенность. Да и со стабильностью в JVM все будет почетче.
Сейчас мир C++ уже далеко ушёл от этого в совсем другую сторону и данный Java-стиль является откровенным legacy
Спорное утверждение, дизайн проверенный временем доказал свое право на существование.
Насчет «не угодил», это, конечно же, была шутка, а прикрываться мне не от чего собственно.
«Вашей кривизны» звучит как-то двусмысленно, будем считать, что это относится к коду :) я так же согласился что это косяк, но боюсь, что существенно на производительность это не повлияет (но надо будет проверить).
В Qt/C++ получились результаты такими какими получились, не вижу смысла там что-то менять, какая библиотека ввода — такой и результат.
Если кто-то напишет хорошую реализация на C++ можно добавить еще и ее для сравнения. Но меня больше интересовали языки с JVM.
Да почему же не смогу? :) Отвечаю.
Отрадно что человек сел и написал код, все лучше чем слюной брызгать :)
Ежели он его еще и опубликует и он окажется адекватным, я добавлю его в тесты и будет у нас полный комплект: современный C++ :)
P.S. Вероятно, товарищ начитался Скотта Майерса, раз уж про «современность» древнего C++ заговорил :)
Ну вот уже что-то :) но при всем уважении на хипе здесь ничего создаваться не будет, все на стеке.
Если QHash не содержит ключа он создаст объект по дефолтному конструктору, что в нашем случае собственно и нужно. Хорошо поправлю, но не думаю что это существенно повлияет на результат. Потому что я проводил подобный эксперимент на Kotlin-е, делал сначала проверку ключа, потом подкладывал — на больших тестах разница была порядка 40-50ms.
Верно. Но Optional мне не нравится, под защитой я имел ввиду:
String str = null; // Ошибка компиляции, тип не поддерживает null
— String? str = null; // OK.
str.length() // Ошибка компиляции (не рантайма!)
Это может отловить кучу проблем на раннем этапе.
mmap это уже завязки на платформу. Понятно, что если все сделать вручную будет быстрее, но это надо тогда в каждом языке делать. Можно в той же Java не пользоваться стандатной библиотекой I/O, а прокинуть нативный вызов и сделать тот же mmap.
Только зачем? Мне интересно было сравнить пользуясь стандартными средствами языка, если его библиотека I/O плохо оптимизирована эту уже минус.
Хорошо, давайте так, я для себя вынес взвешенную оценку C# и в результате сумма его преимуществ и недостатков оказалось ближе к нулю или чуток отрицательной. Т.е. недостатки для меня перевесили преимущества.
Согласитесь что ваш список это тоже не абсолютная истина? Не все поголовно запишут это в преимущества. Кто-то скажет — свойства это круто! Кто-то нет. В той же Java можно реализовать часть этих фич через фреймворки если нужно.
Ну разве я где-то написал что не заметил свойства?
Правда в том, что считать преимуществом, и это уже достаточно субъективно. Безусловно в C# есть свои приятные плюшки, но я не занимался их детальным сравнением в статье, а написал свои общие впечатления о C# в сравнении с Java. Ведь, как известно, на вкус и цвет товарищей нет, кому-то нравится C#, кому-то Java, кому-то Basic…
Я его особо не сравнивал, он у меня отсеялся на стадии «кросплатформенность», хотя вон тут пишут про core.net, надо будет попробовать. Как я уже написал в статье мне он был больше интересен в аспекте производительности.
Из перечисленного Вами списка кое-чем пользовался: свойства, async/await, вариативностью. Еще там достаточно удобно форматировать строки $"".
Я сам удивился, но думаю, что объяснение очень простое, как я уже написал выше, в JVM ввод-вывод лучше оптимизирован чем в Qt, вот и все. Тем более код есть желающие могут с ним поиграть.
Смотри например: msdn.microsoft.com/en-us/en-en/library/system.io.streamreader.discardbuffereddata(v=vs.110).aspx
Я то как раз прекрасно понимаю что я измеряю и как, если ты чего-то не понял из статьи — спрашивай, начнем нагружать тебе мозг :)
Если хочешь предложить что-то конкретное, предлагай — рассмотрим.
P.S. с теми кто обращается на Вы я тоже на Вы, с теми кто на ты, тоже на ты, так что без обид :)
Исполняемый файл будет больше чем jar, но зато в нем будут все «кишки» языка :) если прибавить рантайм Java то он будет весить больше.
Вам самому-то не надоело это муслоить? :) Вроде бы очевидные вещи.
Совершенно не хочется пересказывать ту часть статьи другими словами — кратко «жирные» бинари на мой взгляд это не эстетично, думаю тут есть простор для оптимизации, не более того. А вышеупомянутые языки отсеялись по многим другим факторам, в частности:
А похоже кто-то очень любит поумничать :) ну да ладно все мы тут не без греха :)
Думаю что JVM портирован на большее количество платформ чем тот же Nim и Rust — это кроссплатформенность. Да и со стабильностью в JVM все будет почетче.
Спорное утверждение, дизайн проверенный временем доказал свое право на существование.
Отлично, код в студию! :)
«Вашей кривизны» звучит как-то двусмысленно, будем считать, что это относится к коду :) я так же согласился что это косяк, но боюсь, что существенно на производительность это не повлияет (но надо будет проверить).
В Qt/C++ получились результаты такими какими получились, не вижу смысла там что-то менять, какая библиотека ввода — такой и результат.
Если кто-то напишет хорошую реализация на C++ можно добавить еще и ее для сравнения. Но меня больше интересовали языки с JVM.
Если sbt консоль работает под java и грузит классы в эту же JVM, возможно, и будет некоторый прирост производительности.
Отрадно что человек сел и написал код, все лучше чем слюной брызгать :)
Ежели он его еще и опубликует и он окажется адекватным, я добавлю его в тесты и будет у нас полный комплект: современный C++ :)
P.S. Вероятно, товарищ начитался Скотта Майерса, раз уж про «современность» древнего C++ заговорил :)
Если QHash не содержит ключа он создаст объект по дефолтному конструктору, что в нашем случае собственно и нужно. Хорошо поправлю, но не думаю что это существенно повлияет на результат. Потому что я проводил подобный эксперимент на Kotlin-е, делал сначала проверку ключа, потом подкладывал — на больших тестах разница была порядка 40-50ms.
String str = null; // Ошибка компиляции, тип не поддерживает null
— String? str = null; // OK.
str.length() // Ошибка компиляции (не рантайма!)
Это может отловить кучу проблем на раннем этапе.
Только зачем? Мне интересно было сравнить пользуясь стандартными средствами языка, если его библиотека I/O плохо оптимизирована эту уже минус.
Согласитесь что ваш список это тоже не абсолютная истина? Не все поголовно запишут это в преимущества. Кто-то скажет — свойства это круто! Кто-то нет. В той же Java можно реализовать часть этих фич через фреймворки если нужно.
Правда в том, что считать преимуществом, и это уже достаточно субъективно. Безусловно в C# есть свои приятные плюшки, но я не занимался их детальным сравнением в статье, а написал свои общие впечатления о C# в сравнении с Java. Ведь, как известно, на вкус и цвет товарищей нет, кому-то нравится C#, кому-то Java, кому-то Basic…
Из перечисленного Вами списка кое-чем пользовался: свойства, async/await, вариативностью. Еще там достаточно удобно форматировать строки $"".