Для счастья нужна генерация примерно такого же машинного кода, только из текста лучше читаемого, быстрее написанного, и без граблей на пути. Для этого и создаются Rust/D.
Go привлекает скорее любителей python'а и ruby, чем любителей C++, но теоретически — он мог бы быть «убийцей C++».
А Вы думаете, С++ программисты случайно от него нос воротят? Отсутствие обобщений (generics), а также фокус на богаую стандартную библиотеку делают Go удобным для быстрого прототипирования, где он и соревнуется с python/ruby. Но главное — в обязательном сборщике мусора, который ставит крест на kernel/embedded области. Базовое сравнение есть на Rust wiki.
И, собственно, уже поэтому он не может быть «убийцей C++». Также как и Java не может быть «убийцей C++». Ибо одним из центральных свойств языков BCPL, C, теперь C++ — то, что это «ядерные языки». То есть даже не языки, на которых можно написать ядро OS (хотя это тоже показатель), а то, что «с них всё начинается»: компилятор C написан на C, компилятор C++ написан на C++, все (ну хорошо… почти все) библиотеки в системе так или иначе завязаны на библиотеки соотвествующих языков, etc.
Rust на это вроде как не претендует, так какой из него, нафиг, «убийца C++»?
Rust компилируется в родной машинный код, а сам большей частью написан на Rust. Уже есть несколько проектов операционных систем на нём. Я думаю, уже само их существование сбивает Ваши доводы с ног.
Обойти стороной Rust (как и D) в этой дискуссии было бы ошибкой. Однако, Ваш пост может скорее оттолкнуть потенциальных растовцев (растовщиков? растовчан?). Rust заслуживает лучшего. Дорогие С++-ники, прошу вас оценить этот язык непредвзято. На сегодняшний день это, пожалуй, единственный инструмент для написания C++-совместимого системного кода при безопасной модели памяти.
Альтернативный вариант: MS добавляет поддержку Mantle в Xbox One (дешевле, чем новый стандарт создавать). У NVidia не остаётся выбора. Разработчики счастливы!
Вы же не будете спорить с тем, что единое низкоуровневое API для графики оказало бы феноминально положительный эффект на всю индустрию? Так вот, пока на эту роль кандидат только один — Mantle, и у него уже почти треть рынка (по Вашим цифрам). В идеале Nvidia нужно реализовать поддержку Mantle у себя (или, хотя бы, сообществу вокрут открытых драйверов Nvidia начать двигаться в эту сторону). Естественно, надеяться на то, что MS спокойно останется в стороне, наивно.
Давайте предположим, что MS выкатило свой низкоуровневый API. Единственное железо, которое будет поддерживать его, будет Xbox One. Понятно, что AMD делает это железо, и что AMD было бы проще разработать драйвера для MS API и под Windows, но зачем им идти на этот шаг, когда у них уже есть рабочий Mantle? Nvidia же встанет перед тяжким (в плане денег и репутации) выбором, хотя главное, чтобы они не «пошли своим путём», а то опять канём в эру первобытности и многообразия.
Заключение: MS может и выкатит свой API, но хорошего в этом мало.
A pixel shader runs for each 2x2 pixel area to support derivative calculations (which use x and y deltas).
К MSAA это не имеет отношения — речь идёт не о сэмплах, а о пикселях, и в режиме 2х2 они обрабатываются независимо от MSAA.
Как я уже привел цитату выше из описания от ms — похоже что не фильтруют, но я подозреваю что зависит от вендора.
Фильтрует не драйвер, а движок игры, так что вендор тут не при чём.
Ну ладно, для color они может и отфильтруют, а вот для буфера глубины рендер выполняется гарантированно для каждого семпла.
Вы путаете выполнение фрагментного шейдера с фиксированными блоками (растеризатор, интерполяторы, depth/stencil test). Последние будут работать на частоте сэмплов, что не мешает тяжёлому шейдеру отработать раз на пиксел.
пост процессинг поспроцессингу рознь. Если dof может например скрыть лестницы отсутствия семплинга, то hdr — нет.
Я о том и говорю, что разработчики стараются как можно меньше пост-процессинга делать на частоте сэмплов.
Я лишь опровергаю утверждение «фрагментный шейдер будет выполняться в 4 раза чаще», но пытаюсь показать, что MSAA почти бесплатен. А Вы спорите зря: я на этом собаку сьел, а может и две ;)
Позвольте не согласиться и позанудствовать: фрагментный шейдер выполняется в 4 раза чаще только если на этот настаивают разработчики, и это называется super-sampling. На практике же есть много нюансов:
1) геометрия отрисовывается с тем же вызовом фрагментных шейдеров, а вот этапы rasterizer и pixel export уже будут тяжелее
2) post-processing как правило оптимизируют для того, чтобы минимальную работу делать на уровне сэмплов, так что там часть 4х и часть 1х.
3) полностью заполненные пиксели обычно фильтруют и обрабатывают на уровне пикселей, даже если всё остальное на уровне сэмплов, так что часть из 4х снова уходит в 1х
4) естественно, накладные расходы, требования к памяти и шинам данных — всё это выше
Отставание, вроде бы, несущественное, но если мы сравним максимально достижимую в тесте частоту кадров, то тут разница становится впечатляющей
Максимальный локально-достижимый FPS — это, пожалуй, одна из самых бесполезных характеристик 3D теста. Другое дело, если бы там было максимальное время на кадр.
в отличие от своего собрата OpenGL и других технологий, где есть конкретные операции выделения и освобождения памяти вручную, в WebGL нет такой необходимости
Где это Вы в OpenGL видели конкретные операции выделения памяти? Если речь идёт о GPU, то разницы с WebGL тут никакой (glBufferData, glTexImage*, и другие). Если же Вы об основной памяти — то поясните-ка, где там OpenGL что выделяет, и где Вам в этом помогает WebGL. Насколько я знаю, OpenGL, как и WebGL, оперирует с готовыми кусками основной памяти, выделенными программистом, в распоряжении которого есть множество вариантов языков, для которых доступен OpenGL. К примеру, можно писать на Java/.Net, и там тоже как-бы память подтирать за собой не нужно.
Эх, кто бы так на Rust попробовал и отписАлся… Сверху так посмотришь: Вам на Питоне не понравилась динамическая типизация и отстранённость от железа; а на Хаскеле — что он слишком сложен/оригинален. В Rust же и типизация хоть куда, и стиль повествования привычный, да и близость к железу/библиотекам. Вот только дозреть ему до 1.0, и будет счастье ;)
Жаль, что автор остановился в своём пути на социальных сетях и OS/браузерах. За кадром остались не только кредитки. Хотелось бы ещё увидеть критику современных ISP (Internet Service Provider), DNS, а также способы их обхода. К примеру, опыт подключения к Hyperboria и работы с сервисами в ней (Socialnode, Uppit, HypeOverflow) был бы очень кстати.
Вспомнилось, как в студенческие годы проводил тест на сокамерниках с целью различить 128kbit и 160kbit audio — провалили с треском. Восприятие — штука такая субъективная и неточная…
А Вы думаете, С++ программисты случайно от него нос воротят? Отсутствие обобщений (generics), а также фокус на богаую стандартную библиотеку делают Go удобным для быстрого прототипирования, где он и соревнуется с python/ruby. Но главное — в обязательном сборщике мусора, который ставит крест на kernel/embedded области. Базовое сравнение есть на Rust wiki.
Rust компилируется в родной машинный код, а сам большей частью написан на Rust. Уже есть несколько проектов операционных систем на нём. Я думаю, уже само их существование сбивает Ваши доводы с ног.
В оригинале:
Видимо, SHODAN он тут приводит скорее как антипример.
Давайте предположим, что MS выкатило свой низкоуровневый API. Единственное железо, которое будет поддерживать его, будет Xbox One. Понятно, что AMD делает это железо, и что AMD было бы проще разработать драйвера для MS API и под Windows, но зачем им идти на этот шаг, когда у них уже есть рабочий Mantle? Nvidia же встанет перед тяжким (в плане денег и репутации) выбором, хотя главное, чтобы они не «пошли своим путём», а то опять канём в эру первобытности и многообразия.
Заключение: MS может и выкатит свой API, но хорошего в этом мало.
К MSAA это не имеет отношения — речь идёт не о сэмплах, а о пикселях, и в режиме 2х2 они обрабатываются независимо от MSAA.
Фильтрует не драйвер, а движок игры, так что вендор тут не при чём.
Вы путаете выполнение фрагментного шейдера с фиксированными блоками (растеризатор, интерполяторы, depth/stencil test). Последние будут работать на частоте сэмплов, что не мешает тяжёлому шейдеру отработать раз на пиксел.
Я о том и говорю, что разработчики стараются как можно меньше пост-процессинга делать на частоте сэмплов.
Я лишь опровергаю утверждение «фрагментный шейдер будет выполняться в 4 раза чаще», но пытаюсь показать, что MSAA почти бесплатен. А Вы спорите зря: я на этом собаку сьел, а может и две ;)
1) геометрия отрисовывается с тем же вызовом фрагментных шейдеров, а вот этапы rasterizer и pixel export уже будут тяжелее
2) post-processing как правило оптимизируют для того, чтобы минимальную работу делать на уровне сэмплов, так что там часть 4х и часть 1х.
3) полностью заполненные пиксели обычно фильтруют и обрабатывают на уровне пикселей, даже если всё остальное на уровне сэмплов, так что часть из 4х снова уходит в 1х
4) естественно, накладные расходы, требования к памяти и шинам данных — всё это выше
Максимальный локально-достижимый FPS — это, пожалуй, одна из самых бесполезных характеристик 3D теста. Другое дело, если бы там было максимальное время на кадр.
Где это Вы в OpenGL видели конкретные операции выделения памяти? Если речь идёт о GPU, то разницы с WebGL тут никакой (glBufferData, glTexImage*, и другие). Если же Вы об основной памяти — то поясните-ка, где там OpenGL что выделяет, и где Вам в этом помогает WebGL. Насколько я знаю, OpenGL, как и WebGL, оперирует с готовыми кусками основной памяти, выделенными программистом, в распоряжении которого есть множество вариантов языков, для которых доступен OpenGL. К примеру, можно писать на Java/.Net, и там тоже как-бы память подтирать за собой не нужно.