Очевидно, в данном случае это не так. В абсолютно любом языке чтение всего файла целиком — более эффективно, чем построчное чтение.
Для сравнения языков выбирается наиболее эффективная реализация для каждого языка.
Как мы только что выяснили, не наиболее эффективная, а произвольная.
Если вы посмотрите на различные реализации в одних и тех же языках, то увидите, что бывают очень разные подходы, особенно в вопросах распараллеливания.
И что такие сравнения должны продемонстрировать? Ну вот есть цифры бенчмарков произвольных реализаций произвольных алгоритмов, решающих одну и ту же задачу на двух разных языках. О чем эти цифры говорят? О том, что язык А быстрее языка Б? Нет, алгоритмы же разные использовались. О том, что алгоритм А быстрее алгоритма Б? Нет, реализации же разные. Может хотя-бы о том, что реализация А быстрее реализации Б? Нет, компиляторы же разные, с разным набором оптимизаций.
Хоть убейте, не пойму, как из таких бенчмарков с "наиболее эффективными подходами" можно делать какие-то выводы о скорости языков. Не меряют они скорость языка. Они меряют непонятно что.
Генераторы работают по принципу, известному как «ленивые вычисления». Это значит, что они могут экономить ресурсы процессора, памяти и других вычислительных ресурсов.
Нет, это значит, что они производят вычисления (и тратят "ресурсы процессора, памяти и других вычислительных ресурсов") по мере необходимости, а не наперед вне зависимости от того, нужен ли кому-то результат этих вычислений.
И экономят ресурсы ленивые вычисления только в том случае, когда результаты вычислений не запрашиваются (частично, или, как в статье, совсем). Если же используются все результаты, то ленивые впечатления ничего не сэкономят. В лучшем случае они лишь отложат использование такого-же количества ресурсов. А иногда даже наоборот — добавят накладных расходов.
П.С. Уточню, что последний абзац справедлив только для случаев, когда ленивые и не-ленивые вычисления действительно делают одно и то же. Если не-ленивый вариант помимо вычисления значений еще и занят складыванием их в массивы и выделением памяти под все это добро, то очевидно, в этом случае он действительно может потреблять больше ресурсов, чем его ленивый собрат.
Во-вторых, глупо приплетать свои убеждения к вполне себе техническим проблемам. И уж тем более отталкиваться от своих убеждений при решении таких проблем. Ведь будем честны, ваши слова про удобство использования enum-ов в этом случае вызваны совсем не объективными причинами, а вашими личными убеждениями. Если бы речь в посте шла не про гендеры, а, скажем, про рассы и геймдиз сказал бы добавить к негроидной, европеоидной и монголоидной расам еще австралоидную или даже рептилоидную — вы бы не стали писать комментарий "для рас как раз удобно использовать enum. Т.к. их всего три".
Гейм-дизайнер из поста дал команду добавить поле не с целью глубоко оскорбить нежнейшие чувства St_one и силой вынудить его отказаться от своих безусловно правильных убеждений. Он это сделал по той простой причине, что это может быть полезно для игры и, как следствие, выгодно для компании.
Если в приставке ноута есть слово Pro то это подразумевает профессиональное использование с кучей периферии и пр а не смузи в офисе с пони в обнимку
Сарказм
Если в приставке ноута есть слово Pro то это подразумевает профессиональное использование с кучей падающей на него пыли строительного мусора кирпичей инструментов строителей и пр а не проводочки с флешечками в обнимку.
Еле удержался,
чтобы не поставить хотя-бы парочку запятых
Профессий бывает много и разных. То, что какой-то ноут с приставкой Pro не подходит под лично вашу профессию — не делает его менее профессиональным инструментом. Для множества вполне себе профессиональных людей очень даже профессиональное использование не подразумевает подключения к ноуту флешек, ethernet кабелей, вставки CD-дисков, дискет или подключения еще какого-нибудь допотопного оборудования.
Зато подразумевает, например, подключение 3-4 современных мониторов. Или Быстрого NAS хранилища. Или внешней видеокарты. Или всего этого сразу.
С таким-же успехом можно заключить, что Adobe Premiere Pro — говно, ибо софт с приставкой Pro должен подразумевать профессиональное использование, а в нем даже осцилографа нет.
А как измеряли, если не секрет? Как-то очень уж маловероятно выглядит. 60 мс одни только задержки сети и сервера съедят. А со всякими парсингами и отрисовками даже для статической html уже все 150-200 мс наберутся. И без всяких js анимаций с картинками, подстраивающимися под размер окна.
Если вы делаете сервис типа developers.google.com (т.е. с достаточно уникальным узкоспециализированным контентом, низкой или вообще отсутствующей конкуренцией, отсутствием прямой связи между посещениями страниц и доходом и вообще отсутствием понятия "конверсия") — рекомендации не оправданы. Можете спокойно жить с оценкой 40-60. Ибо те, кому надо — будуть пользоваться сервисом даже если он 10 секунд страницу будет грузить. А те, кому не надо — не будут пользоваться, даже если страница загрузится за 100 мс. Лучше сконцентрироваться на других направлениях развития сервиса.
Но если вы делаете условный амазон, то уменьшение времени загрузки даже на несколько сотен, а то и десятков мс уже может иметь вполне заметное влияние на конверсию. И там есть смысл выжимать скорость по-максимуму и следовать советам PageSpeed. Возле которых, к слову написано, что следование или не-следование им не обязательно повлияет на скорость загрузки и (как следствие) оценку PageSpeed, так что следовать им все равно нужно с умом.
Если была цель скомпенсировать изменения размера, то вместо умножения на 0.8 стоило делить на 1.2. Сейчас там изображение становится в среднем на 2% меньше с каждым преобразованием (1.2 * 0.8 = 0.96).
Ну и по видео очень заметно, что разрешение очень быстро упало за первые секунд 5 и причина явно не в jpeg.
На маке так же. Но для клика нужно именно нажать на тачпад, а не просто коснуться как с типичными PC-тачпадами.
Т.е. даже если защита от случайных касаний не сработает — все, что произойдет на маке — это немного поездит курсор, но нажатий не будет.
устройство с G сетевой картой не имело никаких ограничеиней
Правильно, g устройства и не будут иметь ограничений. Ограничения коснутся n устройств.
Режим совместимости работает так, что если в сети есть хоть одно g устройство, то роутер работает в g режиме со всеми клиентами (в том числе и с n клиентами). Если роутер не умеет в n, то и проблемы как бы "нет", т.к. все в любом случае довольствуются скоростью g. Но если роутер умеет в n, 9 из 10 клиентов в доме умеют в n, но один клиент — только в g, то все 10 клиентов будут работать со скоростью 54 Mbps. При том, что 9 из них могли бы работать на скорости 150-600 Mbps.
Нисколько не ирония, вот пруф про 25 en.wikipedia.org/wiki/Frame_rate
Не нашел в этом пруфе ничего про "человеческий глаз различает не более 25".
По самым последним данным предел разрешения 77 FPS (пруф, если заранее концентрироваться на ожидаемом изображении)
Вы вообще читали свои пруфы? Давайте я перескажу, что там вообще за исследование было, если такие трудности у вас. Людям демонстрировали серию вообще никак не связанных изображений по 13 мс каждое. И этих 13 мс оказалось достаточно чтобы получить концептуальное понимание показанных картинок. Это не имеет вообще никакого отношения к частоте кадров в анимации.
Кстати, я на экране с 60 FPS разницу между 60 и 30 на вашем видео не вижу.
Вероятно это потому, что вы на своем экране с 60 FPS смотрели видео с 30 FPS. 60 FPS youtube дает только для качества 720p+. Нажмите на шестеренку в правом нижнем углу, выберите там нормальное качество видео (которое оканчивается на "p60") и будет вам счастье.
но 165 это уже совсем перебор.
Для вас — может быть. Но это не отменяет того, что разница между теми же 60 FPS и 165 FPS есть. И вполне заметная даже для не особо тренированного человеческого глаза. Для кого-то и разрешение 1366х768 — норм, а всякие там FullHD с 4K — перебор. Но это тоже не отменяет того факта, что разница между 4К и 1366х768 очень даже видна.
Ну если речь про "как должно быть", то софт вообще должен быть без багов. И библиотеки должны быть без багов. И вирусов/троянов/вымогателей не должно быть. Только качественные приложения. И пиратства не должно быть. И вообще преступности. И болезней.
Вот только все эти влажные фантазии (с вашей включительно) не имеют никакого отношения к реальному миру. И пока одни неистово негодуют по поводу того, что "эппл/майкрософт/спортлото не выполняет контракт STL (что бы это не значило), так не должно быть, проблема не моя, фиксить я её не буду" — их пользователи уходят к тем, кто не жлобится на закупку тестовых девайсов и прикручивает костыли для обхода "не выполняющегося контракта STL", невзирая на всю неправильность и несправедливость происходящего.
а Apple перед вами ничем не отвечает. Удобно для Apple, ничего не скажешь. Я думаю, они прямо в восторге от этой ситуации.
Эппл перед разработчиком отвечает ровно в той мере, которая прописана в соглашении, которое разработчик принимал, создавая и выкладывая свои приложения под их платформы. Если разработчику эта мера кажется недостаточной или еще что-либо кажется "неправильным" — он может не разрабатывать приложения под эту платформу и идти зарабатывать деньги на правильных платформах, которые "выполняют контракт STL". Не подскажете такую, кстати?
Ну это в идеальном мире, где можно 2 часа ехать 140 км/ч (ну или 134,4), никогда не притормаживая и не ускоряясь. В реальном мире разница в макс скорости нивелируется сильнее.
C 2015 года гривна не дешевела в три раза к доллару, колебания 10-20%. Но вы можете посмотреть на сколько выросли тарифы на электроэнергию для домохозяйств (подсказка: в разы).
А каким боком тут 2015 год? Вроде как с 2014 сравниваем, не? В начале 2014 года 1 кВт*ч по максимальному тарифу стоял $0,156. В 2019 — $0,0672. По минимальному тарифу — $0,036 в 2014 против $0,036 в 2019. Не подскажете, где именно здесь искать "разы", о которых вы говорили? Точнее разы то я вижу, но только вот эти разы не про рост, а про падение цены.
То, что они выросли "в разы" по сравнению с 2015 годом, говорит лишь о том, что в 2015 году электричество было "в разы" дешевле. А потом цена вернулась к норме (а на самом деле даже ниже, если уже считаем в долларах).
Конечно есть.
Если проект с C++11, то в chrono есть std::chrono::steady_clock. Если на более старом стандарте, то нужно использовать системные вызовы целевой ОС (вроде clock_gettime с CLOCK_MONOTONIC на *nix или QueryPerformanceCounter на винде).
К слову, все это легко находится в гугле по запросу "monotonic time c++/c++03/windows/unix".
Вероятно опечатка) В эппловких языках нет GC, но есть подсчет ссылок. А скажем, в джаве есть GC, а подсчета ссылок нет.
В Python есть и то и другое. Можно рассматривать подсчет ссылок как одну из оптимизаций GC, но в общем случае это независимые вещи, которые прекрасно работают отдельно друг от друга, что видно из примеров выше.
Нет, это разные вещи. С разным механизмом работы, разными возможностями и разным влиянием на производительность.
Простым подсчетом ссылок не определишь, что набор объектов с зацикленными ссылками стал недостижимым (напр. все двусвязные списки из >1 ноды будут утекать. Т.к. в структуре A ⇆ B и на A и на B всегда есть как минимум одна ссылка. Даже когда кроме их самих никто на них не ссылается).
У GC принцип работы другой — он просто обходит всю компоненту связности графа объектов, начиная с "корневого" объекта, и затем убивает все объекты, которые во время этого обхода оказались недостижимыми (на самом деле обходится не весь граф, есть разделение поколений объектов и другие оптимизации, но сам принцип остается прежним — обходим (под-)граф и удаляем все, к чему не дошли).
В контексте хеллоуворлда printf выступает выступает в качестве стандартного способа вывода текста в стандартный поток вывода. В реальном мире она этим и является — стандартным способом вывода текста, используемым по-умолчанию, если нет каких-то особых требований.
Какие преимущества использования узкоспециализированного puts? Процессор впустую подстановки не ищет? Так он и так не ищет, современный компилятор вон оптимизирует такое, как показано в статье. Универсальная printf "не нужна", а специализированная puts нужна? Так это не так работает. В 90% случаев используют общепринятый инструмент прежде всего, а на специализированные переходят если на то есть причины. И "вот конкретно эту вещь специализированный тоже может сделать" — это не причина.
одна из самых сложных и неоднозначных функций Си
При форматированном выводе — да, может быть сложно вспомнить/разобраться во всех этих спецификаторах форматов и типов. Но при выводе строки она не сложнее puts. А по однозначности даже получше будет — не дописывает "самовольно" переводы строк в поток.
Очевидно, в данном случае это не так. В абсолютно любом языке чтение всего файла целиком — более эффективно, чем построчное чтение.
Как мы только что выяснили, не наиболее эффективная, а произвольная.
И что такие сравнения должны продемонстрировать? Ну вот есть цифры бенчмарков произвольных реализаций произвольных алгоритмов, решающих одну и ту же задачу на двух разных языках. О чем эти цифры говорят? О том, что язык А быстрее языка Б? Нет, алгоритмы же разные использовались. О том, что алгоритм А быстрее алгоритма Б? Нет, реализации же разные. Может хотя-бы о том, что реализация А быстрее реализации Б? Нет, компиляторы же разные, с разным набором оптимизаций.
Хоть убейте, не пойму, как из таких бенчмарков с "наиболее эффективными подходами" можно делать какие-то выводы о скорости языков. Не меряют они скорость языка. Они меряют непонятно что.
Нет, это значит, что они производят вычисления (и тратят "ресурсы процессора, памяти и других вычислительных ресурсов") по мере необходимости, а не наперед вне зависимости от того, нужен ли кому-то результат этих вычислений.
И экономят ресурсы ленивые вычисления только в том случае, когда результаты вычислений не запрашиваются (частично, или, как в статье, совсем). Если же используются все результаты, то ленивые впечатления ничего не сэкономят. В лучшем случае они лишь отложат использование такого-же количества ресурсов. А иногда даже наоборот — добавят накладных расходов.
П.С. Уточню, что последний абзац справедлив только для случаев, когда ленивые и не-ленивые вычисления действительно делают одно и то же. Если не-ленивый вариант помимо вычисления значений еще и занят складыванием их в массивы и выделением памяти под все это добро, то очевидно, в этом случае он действительно может потреблять больше ресурсов, чем его ленивый собрат.
Во-первых, речь не про пол, а про гендер.
Во-вторых, глупо приплетать свои убеждения к вполне себе техническим проблемам. И уж тем более отталкиваться от своих убеждений при решении таких проблем. Ведь будем честны, ваши слова про удобство использования enum-ов в этом случае вызваны совсем не объективными причинами, а вашими личными убеждениями. Если бы речь в посте шла не про гендеры, а, скажем, про рассы и геймдиз сказал бы добавить к негроидной, европеоидной и монголоидной расам еще австралоидную или даже рептилоидную — вы бы не стали писать комментарий "для рас как раз удобно использовать enum. Т.к. их всего три".
Гейм-дизайнер из поста дал команду добавить поле не с целью глубоко оскорбить нежнейшие чувства St_one и силой вынудить его отказаться от своих безусловно правильных убеждений. Он это сделал по той простой причине, что это может быть полезно для игры и, как следствие, выгодно для компании.
Если в приставке ноута есть слово Pro то это подразумевает профессиональное использование с кучей падающей на него пыли строительного мусора кирпичей инструментов строителей и пр а не проводочки с флешечками в обнимку.
чтобы не поставить хотя-бы парочку запятых
Профессий бывает много и разных. То, что какой-то ноут с приставкой Pro не подходит под лично вашу профессию — не делает его менее профессиональным инструментом. Для множества вполне себе профессиональных людей очень даже профессиональное использование не подразумевает подключения к ноуту флешек, ethernet кабелей, вставки CD-дисков, дискет или подключения еще какого-нибудь допотопного оборудования.
Зато подразумевает, например, подключение 3-4 современных мониторов. Или Быстрого NAS хранилища. Или внешней видеокарты. Или всего этого сразу.
С таким-же успехом можно заключить, что Adobe Premiere Pro — говно, ибо софт с приставкой Pro должен подразумевать профессиональное использование, а в нем даже осцилографа нет.
А как измеряли, если не секрет? Как-то очень уж маловероятно выглядит. 60 мс одни только задержки сети и сервера съедят. А со всякими парсингами и отрисовками даже для статической html уже все 150-200 мс наберутся. И без всяких js анимаций с картинками, подстраивающимися под размер окна.
По-моему, ответ довольно очевиден.
Если вы делаете сервис типа developers.google.com (т.е. с достаточно уникальным узкоспециализированным контентом, низкой или вообще отсутствующей конкуренцией, отсутствием прямой связи между посещениями страниц и доходом и вообще отсутствием понятия "конверсия") — рекомендации не оправданы. Можете спокойно жить с оценкой 40-60. Ибо те, кому надо — будуть пользоваться сервисом даже если он 10 секунд страницу будет грузить. А те, кому не надо — не будут пользоваться, даже если страница загрузится за 100 мс. Лучше сконцентрироваться на других направлениях развития сервиса.
Но если вы делаете условный амазон, то уменьшение времени загрузки даже на несколько сотен, а то и десятков мс уже может иметь вполне заметное влияние на конверсию. И там есть смысл выжимать скорость по-максимуму и следовать советам PageSpeed. Возле которых, к слову написано, что следование или не-следование им не обязательно повлияет на скорость загрузки и (как следствие) оценку PageSpeed, так что следовать им все равно нужно с умом.
png — это формат с lossless сжатием.
Да, теперь шакалы вполне себе jpeg-овые)
Если была цель скомпенсировать изменения размера, то вместо умножения на 0.8 стоило делить на 1.2. Сейчас там изображение становится в среднем на 2% меньше с каждым преобразованием (1.2 * 0.8 = 0.96).
Ну и по видео очень заметно, что разрешение очень быстро упало за первые секунд 5 и причина явно не в jpeg.
На маке так же. Но для клика нужно именно нажать на тачпад, а не просто коснуться как с типичными PC-тачпадами.
Т.е. даже если защита от случайных касаний не сработает — все, что произойдет на маке — это немного поездит курсор, но нажатий не будет.
Правильно, g устройства и не будут иметь ограничений. Ограничения коснутся n устройств.
Режим совместимости работает так, что если в сети есть хоть одно g устройство, то роутер работает в g режиме со всеми клиентами (в том числе и с n клиентами). Если роутер не умеет в n, то и проблемы как бы "нет", т.к. все в любом случае довольствуются скоростью g. Но если роутер умеет в n, 9 из 10 клиентов в доме умеют в n, но один клиент — только в g, то все 10 клиентов будут работать со скоростью 54 Mbps. При том, что 9 из них могли бы работать на скорости 150-600 Mbps.
Чем вызваны сомнения?
И это не удивительно, потому что там 60 и 120 FPS, замедленные в 4 раза. Т.е. 15 и 30 фпс соответственно.
Вот же коварные обманщики
Не нашел в этом пруфе ничего про "человеческий глаз различает не более 25".
Вы вообще читали свои пруфы? Давайте я перескажу, что там вообще за исследование было, если такие трудности у вас. Людям демонстрировали серию вообще никак не связанных изображений по 13 мс каждое. И этих 13 мс оказалось достаточно чтобы получить концептуальное понимание показанных картинок. Это не имеет вообще никакого отношения к частоте кадров в анимации.
Вероятно это потому, что вы на своем экране с 60 FPS смотрели видео с 30 FPS. 60 FPS youtube дает только для качества 720p+. Нажмите на шестеренку в правом нижнем углу, выберите там нормальное качество видео (которое оканчивается на "p60") и будет вам счастье.
Для вас — может быть. Но это не отменяет того, что разница между теми же 60 FPS и 165 FPS есть. И вполне заметная даже для не особо тренированного человеческого глаза. Для кого-то и разрешение 1366х768 — норм, а всякие там FullHD с 4K — перебор. Но это тоже не отменяет того факта, что разница между 4К и 1366х768 очень даже видна.
Ну если речь про "как должно быть", то софт вообще должен быть без багов. И библиотеки должны быть без багов. И вирусов/троянов/вымогателей не должно быть. Только качественные приложения. И пиратства не должно быть. И вообще преступности. И болезней.
Вот только все эти влажные фантазии (с вашей включительно) не имеют никакого отношения к реальному миру. И пока одни неистово негодуют по поводу того, что "эппл/майкрософт/спортлото не выполняет контракт STL (что бы это не значило), так не должно быть, проблема не моя, фиксить я её не буду" — их пользователи уходят к тем, кто не жлобится на закупку тестовых девайсов и прикручивает костыли для обхода "не выполняющегося контракта STL", невзирая на всю неправильность и несправедливость происходящего.
Эппл перед разработчиком отвечает ровно в той мере, которая прописана в соглашении, которое разработчик принимал, создавая и выкладывая свои приложения под их платформы. Если разработчику эта мера кажется недостаточной или еще что-либо кажется "неправильным" — он может не разрабатывать приложения под эту платформу и идти зарабатывать деньги на правильных платформах, которые "выполняют контракт STL". Не подскажете такую, кстати?
Ну это в идеальном мире, где можно 2 часа ехать 140 км/ч (ну или 134,4), никогда не притормаживая и не ускоряясь. В реальном мире разница в макс скорости нивелируется сильнее.
А каким боком тут 2015 год? Вроде как с 2014 сравниваем, не? В начале 2014 года 1 кВт*ч по максимальному тарифу стоял $0,156. В 2019 — $0,0672. По минимальному тарифу — $0,036 в 2014 против $0,036 в 2019. Не подскажете, где именно здесь искать "разы", о которых вы говорили? Точнее разы то я вижу, но только вот эти разы не про рост, а про падение цены.
То, что они выросли "в разы" по сравнению с 2015 годом, говорит лишь о том, что в 2015 году электричество было "в разы" дешевле. А потом цена вернулась к норме (а на самом деле даже ниже, если уже считаем в долларах).
Конечно есть.
Если проект с C++11, то в
chronoестьstd::chrono::steady_clock. Если на более старом стандарте, то нужно использовать системные вызовы целевой ОС (вродеclock_gettimeсCLOCK_MONOTONICна *nix илиQueryPerformanceCounterна винде).К слову, все это легко находится в гугле по запросу "monotonic time c++/c++03/windows/unix".
Вероятно опечатка) В эппловких языках нет GC, но есть подсчет ссылок. А скажем, в джаве есть GC, а подсчета ссылок нет.
В Python есть и то и другое. Можно рассматривать подсчет ссылок как одну из оптимизаций GC, но в общем случае это независимые вещи, которые прекрасно работают отдельно друг от друга, что видно из примеров выше.
Нет, это разные вещи. С разным механизмом работы, разными возможностями и разным влиянием на производительность.
Простым подсчетом ссылок не определишь, что набор объектов с зацикленными ссылками стал недостижимым (напр. все двусвязные списки из >1 ноды будут утекать. Т.к. в структуре A ⇆ B и на A и на B всегда есть как минимум одна ссылка. Даже когда кроме их самих никто на них не ссылается).
У GC принцип работы другой — он просто обходит всю компоненту связности графа объектов, начиная с "корневого" объекта, и затем убивает все объекты, которые во время этого обхода оказались недостижимыми (на самом деле обходится не весь граф, есть разделение поколений объектов и другие оптимизации, но сам принцип остается прежним — обходим (под-)граф и удаляем все, к чему не дошли).
В Python используются оба этих механизма.
В контексте хеллоуворлда printf выступает выступает в качестве стандартного способа вывода текста в стандартный поток вывода. В реальном мире она этим и является — стандартным способом вывода текста, используемым по-умолчанию, если нет каких-то особых требований.
Какие преимущества использования узкоспециализированного puts? Процессор впустую подстановки не ищет? Так он и так не ищет, современный компилятор вон оптимизирует такое, как показано в статье. Универсальная printf "не нужна", а специализированная puts нужна? Так это не так работает. В 90% случаев используют общепринятый инструмент прежде всего, а на специализированные переходят если на то есть причины. И "вот конкретно эту вещь специализированный тоже может сделать" — это не причина.
При форматированном выводе — да, может быть сложно вспомнить/разобраться во всех этих спецификаторах форматов и типов. Но при выводе строки она не сложнее puts. А по однозначности даже получше будет — не дописывает "самовольно" переводы строк в поток.