Я не задумывался по этому поводу ни минуты. Сейчас тяжелое время. Не вижу причин почему я должен получить от этого выгоду в виде дополнительных выходных. Я могу работать удаленно, я бы работал удаленно если бы не объявили этот странный указ, и буду работать.
За этим популистским указом вижу попытку набрать себе перед выборами или что там процентиков, которые оплатит бизнес
Да, скайп под Windows был хорош когда-то
Проблема в том что он был только под Windows
И вполне возможно что это его и убило. То что он в развитии затормозился это были цветочки по сравнению с тем что на «внезапно» появившиеся android/ios не было нормального клиента.
Как мне видится что рынок (не профессионального) софта таков, что кто первый встал — того и тапки. Тот задает тренды, под него начинает формироваться экосистема, и «подвинуть» его становится очень сложно и зачастую возможно только если сам этот «первый» перестает развиваться. Можно вспомнить сколько времени IE или скайп были актуальны несмотря на наличие более продвинутых альтернатив.
Поэтому возможность запилить новое приложение (которое еще неизвестно найдет ли своего клиента) быстро это вполне себе конкрутнтное преимущество. Тратить на такое же приложение в 3 (условно) раза больше времени потому что натив, и портировать на число платформ (win, mac, linux, web, android, ios — это минимум) без гарантий что у приложения есть клиент — риски вырастают в разы.
Приложения, разработанные не очень быстро проигрывают конкуренцию. Не-кроссплатформенные приложения проигрывают конкуренцию. Приложения без полноценной веб версии тоже имеют все шансы проиграть конкуренцию. Выживает не сильнейший, а наиболее приспособленный.
только к сожалению это довольно быстро разобъется о требование правильно (и быстро) отображать текст со смайликами вида «черная мама и еще одна белая мама с сыном-азиатом», текстом right-to-left и left-to-right в одном абзаце и прочим юникодом, и в т.ч. это WYSIWYG редактировать.
В играх с этим особо не парятся, там в полях ввода даже не всегда выделение и ctrl+v работает.
кроме того, та часть которая не касается скриптинга и отображения (работа с сетью, аппаратное кодировние и декодирование видео и аудио (для видеозвонков, стримов и т.п.), куки, защиты от всевозможных типичных атак вроде xss, ...) остается практически без изменений.
ну и не говоря о том что это будет нещадно тормозить на более-менее сложном контенте (вроде странички с парой тысяч комментов), т.к. в оптимизацию отрисовки хрома под кучу платформ вбуханы миллионы (может даже миллиарды) человеко-часов
При этом шейдер скорее всего будет занимать меньше места чем попытка реализовать что-то подобное на CPU
В общем-то многие из современных демок и являются небольшими программами, которые инициализируют OpenGL/DirectX, и почти весь их объем — один или несколько сложных шейдеров.
К примеру демка из 2010 «elevated» 4кб
вот тут можно посмотреть на ютубе www.youtube.com/watch?v=jB0vBmiTr6o
вот тут портированный на ShaderToy шейдер www.shadertoy.com/view/MdX3Rr
Сам 4кб бинарник можно найти тоже (Windows), только под win10 (и может даже win7) нужно искать пофикшенную версию
Рассмотрим вырожденный пример
Если мы попали в число, которое является степенью двойки, умножим на два. А если не является — уменьшим сразу до 1. Все ли числа уменьшатся до 1 в итоге?
Какая вероятность того что большое число N является степенью двойки? Очень маленькая. И если является, то умножив его на 2 получим еще большее число, которое будет с еще меньшим шансом являться степенью двойки, так?
Не так. Потому что тот факт то что число является степенью двойки изменяет вероятности. И если мы умножим степень двойки на 2, то шанс получить степень двойки оказывается вовсе не случайным событием.
Поэтому то, что «каждое следующее нечетное число будет соответствовать тем же условиям, что и предыдущее» не является фактом и это нужно доказывать. (Кроме того, это еще и не является правдой, судя по всему, только перекос наоборот, в сторону уменьшения)
Такое наблюдение позволяет понять почему «возможно» «большинство» чисел становятся в итоге 1
при этом «возможно» здесь потому что только первая такая операция действительно «случайна», а «случайность» последюущих уже вызывает вопросы
а «большинство» здесь потому что даже маленькая вероятность чего-либо не гарантирует отсутствие таких чисел (к примеру если наивно посчитать вероятность того что число будет простым, то кажется как будто они должны будут кончиться)
Вот в этих то «возможно» и «большинство» и загвоздка
GPU оптимизирована для вычислений с 4-мерными векторами из 32-битных float
Основное место на кристалле занимают регистры (4-мерные) и АЛУ (для 4-мерных операндов)
Если заменить АЛУ и регистры из 4х32 бит на 4х512 бит то энергоэффективности это не повысит никак
На мобилках вообще рекомендуют использовать для вычислений на gpu half (float16) потому что они энергоэффективны и на мобилках это важно (время работы от батареи, throttling). И речь тут именно про вычисления, не текстуры и т.п. память (текстуры в подавляющем большинстве случаев вообще 8 бит на канал fixed-point)
За этим популистским указом вижу попытку набрать себе перед выборами или что там процентиков, которые оплатит бизнес
Проблема в том что он был только под Windows
И вполне возможно что это его и убило. То что он в развитии затормозился это были цветочки по сравнению с тем что на «внезапно» появившиеся android/ios не было нормального клиента.
Поэтому возможность запилить новое приложение (которое еще неизвестно найдет ли своего клиента) быстро это вполне себе конкрутнтное преимущество. Тратить на такое же приложение в 3 (условно) раза больше времени потому что натив, и портировать на число платформ (win, mac, linux, web, android, ios — это минимум) без гарантий что у приложения есть клиент — риски вырастают в разы.
В играх с этим особо не парятся, там в полях ввода даже не всегда выделение и ctrl+v работает.
кроме того, та часть которая не касается скриптинга и отображения (работа с сетью, аппаратное кодировние и декодирование видео и аудио (для видеозвонков, стримов и т.п.), куки, защиты от всевозможных типичных атак вроде xss, ...) остается практически без изменений.
ну и не говоря о том что это будет нещадно тормозить на более-менее сложном контенте (вроде странички с парой тысяч комментов), т.к. в оптимизацию отрисовки хрома под кучу платформ вбуханы миллионы (может даже миллиарды) человеко-часов
Как такое возможно в хоть сколько-то компетентной архитектуре ММО-игры — ума не приложу.
В общем-то многие из современных демок и являются небольшими программами, которые инициализируют OpenGL/DirectX, и почти весь их объем — один или несколько сложных шейдеров.
К примеру демка из 2010 «elevated» 4кб
вот тут можно посмотреть на ютубе
www.youtube.com/watch?v=jB0vBmiTr6o
вот тут портированный на ShaderToy шейдер
www.shadertoy.com/view/MdX3Rr
Сам 4кб бинарник можно найти тоже (Windows), только под win10 (и может даже win7) нужно искать пофикшенную версию
Реньше накладных расходов не было
Теперь накладные расходы есть
Разница в (1/0) = бесконечность раз
Пойду писать статью: Можно уменьшить время выполнения программы в бесконечность раз! (При условии что программа ничего не делает, правда)
Если мы попали в число, которое является степенью двойки, умножим на два. А если не является — уменьшим сразу до 1. Все ли числа уменьшатся до 1 в итоге?
Какая вероятность того что большое число N является степенью двойки? Очень маленькая. И если является, то умножив его на 2 получим еще большее число, которое будет с еще меньшим шансом являться степенью двойки, так?
Не так. Потому что тот факт то что число является степенью двойки изменяет вероятности. И если мы умножим степень двойки на 2, то шанс получить степень двойки оказывается вовсе не случайным событием.
Поэтому то, что «каждое следующее нечетное число будет соответствовать тем же условиям, что и предыдущее» не является фактом и это нужно доказывать. (Кроме того, это еще и не является правдой, судя по всему, только перекос наоборот, в сторону уменьшения)
при этом «возможно» здесь потому что только первая такая операция действительно «случайна», а «случайность» последюущих уже вызывает вопросы
а «большинство» здесь потому что даже маленькая вероятность чего-либо не гарантирует отсутствие таких чисел (к примеру если наивно посчитать вероятность того что число будет простым, то кажется как будто они должны будут кончиться)
Вот в этих то «возможно» и «большинство» и загвоздка
Основное место на кристалле занимают регистры (4-мерные) и АЛУ (для 4-мерных операндов)
Если заменить АЛУ и регистры из 4х32 бит на 4х512 бит то энергоэффективности это не повысит никак
На мобилках вообще рекомендуют использовать для вычислений на gpu half (float16) потому что они энергоэффективны и на мобилках это важно (время работы от батареи, throttling). И речь тут именно про вычисления, не текстуры и т.п. память (текстуры в подавляющем большинстве случаев вообще 8 бит на канал fixed-point)