И вас даже не смутила турбина в голове поезда? Вакуум обеспечивать не рентабельно и слишком сложно, потому предполагается делать разряжение в трубе, но никак не вакуум.
Но если выключить JS скрипты то большинство сайтов работает быстрее и отзывчивее. Видимо еще дело в том что браузер на каждый скрол зачем-то обрабатывает какие-то действия через скрипты.
>Взяли прогу на любом, в принципе, языке, но допустим на обычном js.
>Сунули её в компилятор asm.js, который сделал полный статический анализ программы.
А что по-вашему тогда JIT делает? =) И почему «компилятор asm.js» и «знающий про asm.js jit-компилятор» внезапно будет это лучше делать?
А то что на каждой платформе свой design guideline и свои требования к UX вы указать забыли? Тут никакой html5\js\etc не спасет — вам придется делать РАЗНЫЙ интерфейс под каждую платформу, и лучший это способ — реализовать на нативных элементах. А логика работы запросто делается кроссплатформенной — пишется на нативном языке C\C++, или выносится в облако в виде SaaS.
Если заказчик хочет кастомный интерфейс под кучу платформ — пускай оплатит суппорт UX под каждой платформой, а это будет стоить дорого. А если мы играем в демпинг — вот вам и веб приложения, тормоза, не соответствие design\ux guidelines и тд.
Смотря какой уровень оптимизации, при -O3 gcc и llvm уже вертят функции и методы как им хочется, компилятор обладает полной информацией по сайд эффектам.
из недавнего: printf("%d\n", (int*)3 + 2);
оно настолько UB что попытка узнать что оно выведет на экран покажет познания автора в устройстве процессора: ширина шины, устройство виртуальной памяти, гранулярность доступа (на mips), и тд
Оно надо для того что бы поменьше генов грохалось при рекомбинации, ведь он может произойти по средине гена и тогда ген перестанет кодировать белок или что-то еще. Точно такой же прием используется в генетическом алгоритме если длина гена переменная и мы не имеем возможности найти точку начала или конца гена в последовательности.
А де пункт «быть мотивированным искать лучшие решения, не ограничивать себя границами заданными тз и областью знаний, уметь проводить R&D когда нужно»? Или вы только code-monkey под TDD и таски из таск трекера учите? Junoir от senior'а отличается только мудростью и тем что последний может нафиг послать и за пару дней предложить решение в таком виде о котором заказчик и все сотрудники раньше и не слышали.
Очень часто я наблюдаю у хороших специалистов тупо страх перед новыми вещами за ихней областью знаний. Если сразу не вдолбить что это плохо — получите программистов которых никогда и не взяли бы в гугл\фейбсук и тд =)
Думаю они допилят драйвера тегры 3\4 под OpenGL ES 3.0, эти чипы не держат только ETC\ETC2 и FP32, первое можно декодировать в понятный для тегры формат на лету внутри драйвера, второе в принципе не сильно важно, разве что вы умножаете model и view матрицы в шейдере, но тогда у вас возникли бы всякие подёргивания и тд куда раньше чем вам реально понадобилось бы FP32. Даже наоборот — тегра держала MRT и PBO когда остальные еще плясали вокруг OpenGL ES 2.0.
Большинство вещей из OpenGL ES 3.0 можно сделать на банальных чипах SGX 543 и подобных, просто драйверописатели ну очень ленивые, один и тот же чип (SGX 543) имеет разный функционал в разных устройствах: в PS Vita есть MRT (хотя там нету OpenGL вообще, там свой GAPI), а в устройствах на базе Apple A5 и iOS до 7 нету, как это понимать? PBO в мобильных системах делается вообще очень просто, ведь зачастую RAM и VRAM это один и тот же чип памяти и PBO это просто отдать поинтер из памяти. В iOS есть даже PBO-подобный функционал через CoreVideo, но сделать расширение для OpenGL ES? Неее, это они не могут\это им лень. Так что тегра в этом свете даже молодец — они первые реализовали критически важные расширения когда остальные ждали новой волны GPU чтобы поднять свой зад и сделать наконец-то штуки из OpenGL ES 3.0, в старых чипах наверно этого и не будет, ведь зачем портить жизнь маркетологам? Новые ГПУ ведь надо же как-то толкать.
После опыта разработки под PS Vita я очень сердит на всех разработчиков драйверов под мобильные системы. Под витой я мог красиво получать C поинтеры на объекты, буфера, текстуры, и потом читать и писать их как захочу, мог формировать буфер команд гпу и потом просто отсылать уже сформированый буфер, имел всякие плюшки типа профилировщика и анализатора шейдеров, имел тот же MRT, имел по пиксельный дебаг как DirectX — можно было поставить брекпоинт на пиксель и посмотреть что туда рисовалось. А под iOS\Android я не имею вообще ничего, только под iOS я внезапно могу посмотреть буфер OpenGL команд и абстрактные метрики «я сожрало 50 мб видеопамяти». Единственное что выделилось на фоне этого уг — NVidia, со своим NVidia Nsight и NVidia PerfHud ES, подобного софта тупо нет ни для SGX чипов, ни для Mali, ни для Adreno. А нужная для оптимизации информация есть только у Unity3D, потому что они договорились со всеми, подписали NDA и похоже имеют доступ к архитектуре разных гпу и способах оптимизации.
Потому что считаю крики «NVidia не может в OpenGL ES 3.0» не больше чем маркетинговым ходом.
В Украине вот сделали обмен валют только с паспортом (делают ксерокопию паспорта при обмене валют), не знаю от чего боролись, а напоролись на то что базу паспортов теперь можно купить по 1.5-4$ за паспорт.
Я использую virtuawin на 4 виртуальных декстопа по 2 монитора по 1680*1050 — мало потому что на двух мониторах еле помещается 2 msvc и 2 инстанса игры, а нужно еще держать перед глазами браузер с таск менеджером (jira), и еще полезно держать перед глазами git клиент. Скайп, музыкальный плеер и браузер находятся на других виртуальных десктопах.
На работе два моника 1680*1050, домой хочу взять два Dell UltraSharp 32 (только стол надо новый купить) и калибратор на них (Spider какой нить), софт калибраторов кстати сейчас через веб страничку умеет и всякие айпады калибровать. Моники надо потому что для дебага реалтайм сетевых приложений (игры) много места не бывает: несколько инстансов игр и сервер (игра это как минимум окошко 1024*768), несколько инстансов IDE — msvc, wireshark, браузер, скайп еще нужно поместить куда-то. Плюс иногда возникает потребность работать одновременно и с виндой и с маком.
Например в ГОСТ 28147-89 есть дополнительная информация (S-блоки). Один набор блоков был приведен в ГОСТ Р 34.11-94, и он же используется центральным банком РФ. Если использовать другой набор блоков то алгоритм останется таким же. Потому S-блоки здесь не являются частью алгоритма. Только две реализации алгоритма с разными S-блоками не совместимы между собой, в этом и идея, что можно такие данные зашить аппаратно и это значительно повышает криптостойкость алгоритма. Но ничего не спасет против человека который полезет реверсить аппаратный блок, хотя тогда ему значительно проще получить доступ к охраняемой системе, чем ломать криптографию (те — угнать автомобиль).
Как бы если делать полный аппаратный реверс инжениринг криптографических систем то тут уже ничего не спасёт. Ведь основа криптографии — открытые алгоритмы и закрытые данные (ключи, таблички, etc). Алгоритмы доступны в википедии, а закрытые данные — имея аппаратный доступ. Только вот закрытые данные могут быть разными для каждого отдельно взятого устройства (автомобиля), а могут быть как обычно =)
Не понятно правда что именно они взломали? Закрытый ключ принимающей стороны? Алгоритм чексумы? Протокол общения?
В реалтайм сетевой игре у каждого клиента «свой мир» и серверу нужно чётко проверять не только по дельтам времени, а то получится что клиент у себя убил противника, а на сервере противник уже чуть сдвинулся и клиент не попал.
Для шахмат можно считать что событие произошло когда пришло на сервер, для реалтайм (об этом статья же) например стрелялки (fps и не только) — это не так, игрок нажал на кнопку и догадайтесь когда игра должна среагировать? Верно — сразу же, точнее — через 1-2 кадра, это 16-32 мс. Ответ от сервера прийдет как минимум через 100 мс, если рендер будет рисовать ответы от сервера то будет жесткое ощущение лагов и в такую реалтайм игру никто играть не будет. Потому время на клиенте как раз «сейчас», а серверу приходится существовать в «будущем», да еще таком что время любого клиента было меньше времени сервера, но время сервера не было сильно больше времени любого клиента, иначе слишком много нужно данных хранить о действитях клиентов. Поскольку все клиенты имеют время «сейчас», а канал связи между ними — 2 пинга, то экстраполяция наше всё, без неё вообще никак. Так устроены все сетевые стрелялки, а это самые требовательные к сетевой составляющей игры.
>Сунули её в компилятор asm.js, который сделал полный статический анализ программы.
А что по-вашему тогда JIT делает? =) И почему «компилятор asm.js» и «знающий про asm.js jit-компилятор» внезапно будет это лучше делать?
Если заказчик хочет кастомный интерфейс под кучу платформ — пускай оплатит суппорт UX под каждой платформой, а это будет стоить дорого. А если мы играем в демпинг — вот вам и веб приложения, тормоза, не соответствие design\ux guidelines и тд.
оно настолько UB что попытка узнать что оно выведет на экран покажет познания автора в устройстве процессора: ширина шины, устройство виртуальной памяти, гранулярность доступа (на mips), и тд
Очень часто я наблюдаю у хороших специалистов тупо страх перед новыми вещами за ихней областью знаний. Если сразу не вдолбить что это плохо — получите программистов которых никогда и не взяли бы в гугл\фейбсук и тд =)
Большинство вещей из OpenGL ES 3.0 можно сделать на банальных чипах SGX 543 и подобных, просто драйверописатели ну очень ленивые, один и тот же чип (SGX 543) имеет разный функционал в разных устройствах: в PS Vita есть MRT (хотя там нету OpenGL вообще, там свой GAPI), а в устройствах на базе Apple A5 и iOS до 7 нету, как это понимать? PBO в мобильных системах делается вообще очень просто, ведь зачастую RAM и VRAM это один и тот же чип памяти и PBO это просто отдать поинтер из памяти. В iOS есть даже PBO-подобный функционал через CoreVideo, но сделать расширение для OpenGL ES? Неее, это они не могут\это им лень. Так что тегра в этом свете даже молодец — они первые реализовали критически важные расширения когда остальные ждали новой волны GPU чтобы поднять свой зад и сделать наконец-то штуки из OpenGL ES 3.0, в старых чипах наверно этого и не будет, ведь зачем портить жизнь маркетологам? Новые ГПУ ведь надо же как-то толкать.
После опыта разработки под PS Vita я очень сердит на всех разработчиков драйверов под мобильные системы. Под витой я мог красиво получать C поинтеры на объекты, буфера, текстуры, и потом читать и писать их как захочу, мог формировать буфер команд гпу и потом просто отсылать уже сформированый буфер, имел всякие плюшки типа профилировщика и анализатора шейдеров, имел тот же MRT, имел по пиксельный дебаг как DirectX — можно было поставить брекпоинт на пиксель и посмотреть что туда рисовалось. А под iOS\Android я не имею вообще ничего, только под iOS я внезапно могу посмотреть буфер OpenGL команд и абстрактные метрики «я сожрало 50 мб видеопамяти». Единственное что выделилось на фоне этого уг — NVidia, со своим NVidia Nsight и NVidia PerfHud ES, подобного софта тупо нет ни для SGX чипов, ни для Mali, ни для Adreno. А нужная для оптимизации информация есть только у Unity3D, потому что они договорились со всеми, подписали NDA и похоже имеют доступ к архитектуре разных гпу и способах оптимизации.
Потому что считаю крики «NVidia не может в OpenGL ES 3.0» не больше чем маркетинговым ходом.
Не понятно правда что именно они взломали? Закрытый ключ принимающей стороны? Алгоритм чексумы? Протокол общения?