Это как парадокс, что пользователи чаще пишут отзыв при плохом происшествии; когда же все идет отлично, они молчат — люди просто не обращают внимание, что все хорошо. Я могу вам назвать, когда const действительно полезен — прежде всего при отладке. Как только у вас что-то идет не так, а особенно в трудностях локализации ошибки — const в аргументах и теле позволяют сразу сказать: «Ага, я не модифицировал это значение, значит ошибка не тут!». В частности может помочь, когда переполнение буфера (да, я в курсе про address sanitizer, но предположим его у вас нет), и все выглядит, словно изменяется именно эта переменная.
Кстати по поводу const — любопытный факт, но далеко не всегда в ситуациях при оптимизации, где, казалось бы, компилятор должен догадаться о неизменяемости, он действительно догадывается. Помню, пол-года назад мне надо было оптимизировать прогу под встраиваемое устройство. Можно было переписать часть функций, превратив их в трудноотлаживаемую мешанину, но по опыту в будущем ни к чему хорошему это бы не привело. Поэтому — помимо игр с опциями оптимизаций компилятора — огромная часть проделанной работы оказалась простым путешествием по всем замешанным функциям кода, и заменой переменных и аргументов на const везде, где только можно. Работала такая оптимизация прежде всего со всякими векторами и структурами. Для проверки, сработало ли в очередной раз, достаточно перекомпилировать один объектный файл с оптимизациями — и, если размер уменьшился, следовательно компилятор смог применить еще какую-то оптимизацию.
Стоп, мы ведь говорим о платформах с сишными библиотеками, как SDL? Да, соберется. И да, компиляция статическая, т.к. происходит проверка типов по всем модулям. Ну, а Lua не статически типизирован, и хотя, наверное, изредка это удобно — например, как вы выразились, подправить что-то на конечном дейвасе — в разработке от этого больше проблем. Чем больше проект, тем сложнее писать на динамическом языке, именно потому что все проблемы всплывают на конечном девайсе, куда это все еще надо загрузить и запустить ;)
Как пример таких проблем могу вспомнить питоновский PyUNO — объективно, это не вина языка, просто это самое отвратительное АПИ какое я когда-либо встречал. Штука в том, что половина его проблем исчезла бы, если бы АПИ было на статическом языке.
Да, в идеальном мире, конечно, надо бы, чтобы новые мессенджеры развивали плагины под другие клиенты, или хотя бы держали открытым протокол.
Например я сейчас доступен из ВК, Facebook, Skype, IRC, GTalk — при этом клиент у меня единственный, Pidgin. Все доустановлено плагинами. Печалит лишь, что многие плагины написаны реверс-инжинирингом, что нестабильная штука.
Вы говорите, что благодаря кэшу улучшение от доп. регистров нивелируется. Но хочу заметить, что могут быть оптимизации, где при большом кол-ве регистров можно убрать команды загрузки/выгрузки данных между регистром и памятью, что должно чуть сократить код, и улучшить скорость.
Это миф, 64 бит не едят в два раза больше 32 бит. Да, указатели и int больше размером. Но большую часть памяти обычно занимают массивы и пакованные структуры, которые, как правило, одного размера при любой битности. Я уж не говорю, что компиляция под 64 бит подразумевает возможность оптимизации как минимум под SSE и SSE2.
Нет, могут быть крайности, но это редкость. Да что я вам рассказываю — мы рассуждаем прямо под статьей с бенчмарками, показывающими разницу в памяти отнюдь не в два раза. Особенно это можно заметить на примере Chrome, очевидно его неплохо оптимизировали.
Не имел таких намерений. Просто в беседе с людьми, не знающими о предмете разговора, лучше всего применять аналогии — а питон довольно популярен, был упомянут в статье, и ближе всего по синтаксису (хотя, конечно, не по мышлению).
Ну вы сильно преувеличиваете. Только что полюбопытствовал: на моем старом ноуте чистая система (ну ладно, с «konsole»), со включенной прозрачностью при движении, «дрожащими окнами», включенными четырьмя рабочими столами, и др. включенными эффектами, занимает всего 628Мб — и да, я чуть пощелкал, подождал пока все наверняка загрузится.
Не имея столь требовательных приложений, работая на 3Ггб, могу сказать, что от 8Ггб и выше не отказался бы. RAM дешева, а «лишней памяти не бывает» — пускай под кэш используется.
Хотя не понимаю людей, пользующих 32-бит, при поддержке CPU 64-ех, но хочу заметить, что PAE не костыли. Во-первых он реализован аппаратно, и производительности (в сравнении с чистым х86-32) не вредит — ну, может, в пределах погрешности. Во-вторых: как это мы их не видим — в большинстве 32-битных современных популярных ОС PAE включен по-умолчанию. В-третьих, насколько мне известно, руками возможно включить PAE, даже под несерверной WindowsXP, из чего предполагаю, что в последующих версиях тоже (если, она там не включена по-умолчанию).
Я вот, например, не понимаю людей, которые не в мобильных-дорожных, а обычных условиях занимаются работой только на ноутбуке, да ещё зачастую без мыши, как это им удаётся достичь в таких условиях высокой продуктивности.
От раб. окружения зависит. Если у вас тайловый оконный менеджер, vim-подобный редактор, и расширение типа Pentadactyl в браузере — вы пальцы не то что на мышь, даже с алфавитной части клавиатуры на часть со стрелками (в ноутах нередко расположенную отвратительно для слепого набора) перемещать не будете.
Мне кажется, вы не в ту степь полезли, т.к. относительно нашего спора я вообще не вижу аналогии между «OpenGL вместе с DirectX» и «Linux vs Windows». Давайте еще раз: вот есть на Windows несколько АПИ для работы с ресурсами GPU. Реализуют это АПИ драйвера GPU. Вендорам невыгодно реализовывать одно граф. АПИ посредством другого — именно потому, что если конкурент все сделает как надо, его аналогичная по характеристикам GPU будет на одном из АПИ быстрее. Поэтому OpenGL поверх DX — это прерогатива исключительно родных дров от Microsoft, с которыми все равно никто не сидит, т.к. они и без того медленнее родных вендорских дров, по ряду других причин.
А для поставщика дров, как NVidia или AMD, нет понятия «конкурирующий графический АПИ» — у них просто есть набор стандартов, и им надо их все реализовать, и по возможности эффективно, т.к. пользователи могут использовать любой из них, в том числе все сразу. И в понятие эффективности не входят «тормоза, если кто-то на ПК воспользовался OpenGL и DirectX одновременно».
Я полагаю, что тестировали с помощью того, что нативно работает на обоих ОС. Вероятно до вас никому в голову не приходило, что это плохие тесты. Но в любом случае, у вас есть идеи других бенчмарков, которые нативно работают на Win и GNU/Linux? К слову говоря, Phoronix к читателям прислушиваются.
Согласно вашему предположению во втором параграфе, работа одинаково ухудшается для обоих API :) В любом случае, смею вас заверить, что это не так. Оба API — это просто библиотечные функции, которые в конечном итоге переходят в низкоуровневый код драйвера, где «АПИ» для одинаковых операций, одно и то же. На том уровне разницы между DX, OpenGL, Vulkan, или что там еще придумают — нет.
Результаты тестов и игр связаны очевидным образом.
Ваш SteamOS был обойден Windows, наверняка, на другой GPU — не на все из них, к сожалению, хорошие дрова. Я привел пример хороших, и для меня это имеет смысл, т.к. я еще не покупал ПК, и подобные тесты позволяют мне выбрать хорошую модель, а не кота в мешке.
Конечно «синтетический тест», такие тесты есть во многих играх. А как еще вы предлагаете сравнивать производительность? Нельзя просто запустить игру, побегать, и записать FPS — у вас будут отрисовываться разные части, разные эффекты, разный код исполняться.
И нет, если вы поставили дрова от производителя, а не остались с теми, что шли в коробке от Майкрософт — то у вас OpenGL не поверх DX.
Ну я же писал: собирая с нуля ПК, несложно посмотреть, на какой GPU хорошие дрова. И как минимум ничего не потерять, а как максимум, так еще и выиграть.
Как пример таких проблем могу вспомнить питоновский PyUNO — объективно, это не вина языка, просто это самое отвратительное АПИ какое я когда-либо встречал. Штука в том, что половина его проблем исчезла бы, если бы АПИ было на статическом языке.
Например я сейчас доступен из ВК, Facebook, Skype, IRC, GTalk — при этом клиент у меня единственный, Pidgin. Все доустановлено плагинами. Печалит лишь, что многие плагины написаны реверс-инжинирингом, что нестабильная штука.
Нет, могут быть крайности, но это редкость. Да что я вам рассказываю — мы рассуждаем прямо под статьей с бенчмарками, показывающими разницу в памяти отнюдь не в два раза. Особенно это можно заметить на примере Chrome, очевидно его неплохо оптимизировали.
И коль упомянут Python — я бы назвал Haskell как раз статически типизированным питоном.
А для поставщика дров, как NVidia или AMD, нет понятия «конкурирующий графический АПИ» — у них просто есть набор стандартов, и им надо их все реализовать, и по возможности эффективно, т.к. пользователи могут использовать любой из них, в том числе все сразу. И в понятие эффективности не входят «тормоза, если кто-то на ПК воспользовался OpenGL и DirectX одновременно».
Согласно вашему предположению во втором параграфе, работа одинаково ухудшается для обоих API :) В любом случае, смею вас заверить, что это не так. Оба API — это просто библиотечные функции, которые в конечном итоге переходят в низкоуровневый код драйвера, где «АПИ» для одинаковых операций, одно и то же. На том уровне разницы между DX, OpenGL, Vulkan, или что там еще придумают — нет.
Ваш SteamOS был обойден Windows, наверняка, на другой GPU — не на все из них, к сожалению, хорошие дрова. Я привел пример хороших, и для меня это имеет смысл, т.к. я еще не покупал ПК, и подобные тесты позволяют мне выбрать хорошую модель, а не кота в мешке.
И нет, если вы поставили дрова от производителя, а не остались с теми, что шли в коробке от Майкрософт — то у вас OpenGL не поверх DX.