Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 75
«новые поколения будут оглядываться на исторический период с 1963 по, ну, допустим сегодняшний день, и вздыхать тоскливо: „Наверное, это было самое захватывающее время во всей истории человечества“»
Что-то мне подсказывает, что так и будет.
Что-то мне подсказывает, что так и будет.
Скептиков не любят на хабре, бро.
любят
Неоправданный оптимизм — тоже плохо. Вообще любые крайности плохо. По информации, которой я располагаю сейчас, мне очевидно, что все темпы развития начнут спадать со временем. Подобное ведь что-то уже было в 19 веке, тоже очень много чего нового и интересного появилось. А что потом имеем в начале двадцатого века?
Я имею в виду не крайне узкую направленность, а какое-то развитие охватывающее более широкие слои населения. Ведь под «потомки будут думать что это было самое захватывающее время в истории человечества» явно это не подразумеваются какие-то эксперименты британских ученых в лабораториях, а нечто, к чему имеют доступ много людей. Вы считаете очень интересным «СТО, кванты, строение атома, радиоактивность»? Я не говорю про полезность, а именно Вам это интересно?
Предвидя, что просто чтоб со мной поспорить Вы отвечаете — «Да», скажу, что под интересом я подразумеваю то, чему Вы считаете нужным посвятить основное свое время. Иначе если программируете, но «кванты, атомы» интереснее, то как-то печально выходит.
Предвидя, что просто чтоб со мной поспорить Вы отвечаете — «Да», скажу, что под интересом я подразумеваю то, чему Вы считаете нужным посвятить основное свое время. Иначе если программируете, но «кванты, атомы» интереснее, то как-то печально выходит.
Резерфорд — 1905 год — открытие планетарной структуры атома.
Атомная энергетика за каких-то 50 лет, несмотря на все споры и т.д., отхватила 3% мировой энергетики, и эта цифра будет только расти.
Фон нейман — изобретение современной архитектуры компьютера — создание ЭВМ, без которых сегодня не обходится ничего. Хотите сказать, что электричеством и «компьютером» пользуются одни британские ученые в лабораториях?..
И это только самые яркие исследования. Сколько всего было обнаружено в химии, биологии, экономике…
Атомная энергетика за каких-то 50 лет, несмотря на все споры и т.д., отхватила 3% мировой энергетики, и эта цифра будет только расти.
Фон нейман — изобретение современной архитектуры компьютера — создание ЭВМ, без которых сегодня не обходится ничего. Хотите сказать, что электричеством и «компьютером» пользуются одни британские ученые в лабораториях?..
И это только самые яркие исследования. Сколько всего было обнаружено в химии, биологии, экономике…
Мы сравниваем лишь темпы развития. В девятнадцатом веке темпы были более захватывающими. Понятно что в 20 веке будет что-то новое и захватывающее, но так ли много как в 19? И не забывайте, что это «захватывающее» часто означает лишь то, насколько оно повлияло на жизнь людей и насколько люди это понимают. Т.е. изобретение радио, телефона вызывает гораздо больший вау-эффект, чем открытие строения атома и все остальные открытия в химии, биологии, экономике.
ммо рпг, контактик, твиттер, фейсбук — куда уж более «ВАУУ» и попсовей я и не знаю даже…
Именно, я про это и говорю. Но Вы не упомянули самое важное, на чем все это стоит — Интернет. Но в чем конкретно Вы не согласны я не до конца понимаю?
Скорее интернет стоит на ЭВМ, а не наоборот.
С чем я не согласен? А разве непонятно? Ваши слова, фактически, «XX век не дал человечеству ничего принципиально важного, в отличие от предыдущих». С тем же успехом можно говорить, что со времен изобретения колеса не было никаких выдающихся открытий, сопоставимых по значимости. Насчет «узкой направленности» — электричество было открыто еще в древней греции (эбонитовая палочка, знаете наверное), однако более-менее значимых успехов добились лишь с приходом таких людей, как Тесла, Эдисон, Максвелла и прочих. Многие теоретические «непонятные и заумные» математики находят такое применение, о котором даже помыслить никто не мог. Даже квантмехом сейчас пользуются — те же туннельные диоды построены на них. Или по-вашему то, что используется в электронном оборудовании, 100% уходит в бункер к британским ученым? То, что вы не знаете, с чем работаете, не означает, что это фигня. Это как в древнем Риме, люди думали «ах, нафига нам математика (некоторые), она нужна только саксонским ученым в подземных казематах», однако акведуком пользовались исправно…
С чем я не согласен? А разве непонятно? Ваши слова, фактически, «XX век не дал человечеству ничего принципиально важного, в отличие от предыдущих». С тем же успехом можно говорить, что со времен изобретения колеса не было никаких выдающихся открытий, сопоставимых по значимости. Насчет «узкой направленности» — электричество было открыто еще в древней греции (эбонитовая палочка, знаете наверное), однако более-менее значимых успехов добились лишь с приходом таких людей, как Тесла, Эдисон, Максвелла и прочих. Многие теоретические «непонятные и заумные» математики находят такое применение, о котором даже помыслить никто не мог. Даже квантмехом сейчас пользуются — те же туннельные диоды построены на них. Или по-вашему то, что используется в электронном оборудовании, 100% уходит в бункер к британским ученым? То, что вы не знаете, с чем работаете, не означает, что это фигня. Это как в древнем Риме, люди думали «ах, нафига нам математика (некоторые), она нужна только саксонским ученым в подземных казематах», однако акведуком пользовались исправно…
я думаю, все еще впереди…
Главное вырваться в космос или наоборот в гулбины планеты, и начать там развиваться… это тоже очень «захватывающее время во всей истории человечества»… еще ведь столько не изведано…
Главное вырваться в космос или наоборот в гулбины планеты, и начать там развиваться… это тоже очень «захватывающее время во всей истории человечества»… еще ведь столько не изведано…
«Сегодня — китайцы на Луне, завтра — миллионы нелегалов на Марсе!»
Эх, кто бы пластиковые бутылки из океанов отловил… А вы про космос…
Эх, кто бы пластиковые бутылки из океанов отловил… А вы про космос…
Если бы оно там все бутылками и пакетами плавало, то отловить не проблема. Но фотодеградация все портит, там мелкие частицы в пару миллиметров в толще воды до 20 метров с концентрацией в среднем 5.1кг/км^2
Проблема отловить и не погубить весь планктон в процессе. Но работа в этом деле идет и даже спонсируется.
Проблема отловить и не погубить весь планктон в процессе. Но работа в этом деле идет и даже спонсируется.
Ну, если бы мы были в некотором не очень отдаленном будущем, я бы предложил использовать ГМ-организмы. Сложно сказать, какие именно, возможно, планктон.
Бактерии, которые жрут полимеры уже придумали, вроде как, осталось развить идею.
Бактерии, которые жрут полимеры уже придумали, вроде как, осталось развить идею.
Правда? Это радостная весть для меня. Надеюсь, человечество таки приберёт за собой.
Будут вспоминать примерно как вспоминали эпоху золотой лихорадки, но лишь до новой подобной эпохи, которая точно не за горами. Есть у нас много путей развития еще, где возможен взрывной рост.
Перечислите?
Я бы поставил на медицину и биология в целом. Сложно рассказать основной массе людей, почему нужно тратить тонны денег на освоение космоса. А частным инвесторам, еще сложнее. Тогда как за продление жизни, молодости или даже банальные твики огранизма готовы заплатить очень многие. Когда высокие технологии замедлятся в развитии, думаю, инвестировать будут именно туда, в биотехнологии.
Но даже если процессоры не станут в ближайшее время сильно быстрее, IT еще есть куда развиваться;) Собственно, на рост мощности процессоров уже много лет особо не рассчитывают, закон Мура работает больше в пользу многоядерности.
Но даже если процессоры не станут в ближайшее время сильно быстрее, IT еще есть куда развиваться;) Собственно, на рост мощности процессоров уже много лет особо не рассчитывают, закон Мура работает больше в пользу многоядерности.
ну кстати, да: ru.wikipedia.org/wiki/Список_новых_перспективных_технологий
Я несколько недопонял статью. HTML5 считается чем-то вроде серебряной пули, так? Почему так плохо делать нативные (кстати, имхо native лучше не переводить) приложения? Потому что это предполагает найм двух лишних программистов (WP+iOS+Android)? А с каких пор и в какой ещё отрасли создание лишних рабочих мест начало быть плохим признаком?
P.S.: Да, статья не совсем об этом. Но мне действительно интересно, почему аксиоматизируется тормознутость и безальтернативность HTML5? Может эти и подобные условия дали неверный вывод?
P.S.: Да, статья не совсем об этом. Но мне действительно интересно, почему аксиоматизируется тормознутость и безальтернативность HTML5? Может эти и подобные условия дали неверный вывод?
Не задавай вопросов, это просто топик зла.
Люди которые что-то пишут, даже в хороших источниках… Как бы это сказать помягче…
Не всегда достаточно, назовем это, квалифицированные.
Не всегда достаточно, назовем это, квалифицированные.
А с каких пор и в какой ещё отрасли создание лишних рабочих мест начало быть плохим признаком?Где-то с середины девяностых золотой мечтой всех контор, производящих прикладные приложения, было снижение потребной квалификации разработчика. Т.е. количество-то фиг с ним, пусть даже вдвое вырастет, но это должны быть люди «недорогие» (т.е. порог вхождения в технологию должен быть минимальным) и «неспециализированные» (чтобы не создавались «тайные знания», в результате которых растет цена работника).
Что убийца флэша не состоялся? Зато везде флэш-плеер на мобилах отключили вместо того чтобы тупо сделать его запуск по тапу.
Мой прогноз: да, темпы смены ИТ-технологий замедлятся и, может быть, даже существенно. Но будет новая тема, которая сейчас пока только разгоняется и поэтому не сильно заметна. Например, биотехнологии, генетика, психология, да хз что. Может, даже, что совсем экстравагантное вроде нового вида транспорта или жилья.
И это тоже поменяет мир также, как во второй половине 20 века сделали компьютеры и электроника.
Запомните дату поста и поставьте напоминалку в гугл, 15.07.2033 проверите.
И это тоже поменяет мир также, как во второй половине 20 века сделали компьютеры и электроника.
Запомните дату поста и поставьте напоминалку в гугл, 15.07.2033 проверите.
Добро, добро, добро!
Это пост зла?
Законы Мура и развития процессорной техники так же как релятивистская и квантовая межаники не одно и то же, Не стоит создавать аксиомы там где ты незнаещь в каком направлении пойдёт наука в этой области. Или хотя бы ограничить их рамками используемых технологий и их граничных возможностей. На мой взгляд, прогресс, так же имеет волновую природу, Сегодня мы достигаем минимума но прийдёт кардинально новая технология и все волна начнет опять нарастать. И именно этот минимум заставит копать с утроенной энергией ниву технологий. Посмотрим.
Глобально пути назад для маятника нет.
В некоторых локальных нишах маятник действительно качнется в сторону вылизывания кода, но в глобальном масштабе индустрии растут сами масштабы решаемых задач, а путей по развитию практически не видно. Распределенные системы уже уперлись в скорость света и фундаментальную плохую распараллеливаемость подавляющего большинства известных решений подавляющего большинства задач.
В случае прорыва в математике-алгоритмизации прогресс в вычислениях продолжиться, но фундаментально проблему может решить только прорыв в аппаратных технологиях, будь то квантовые сопроцессоры или компьютеры или еще что-нибудь…
P.S. В мобильных же технологиях главная проблема не столько вычислитель, сколько аккумулятор. Пока в них прогресса не будет качественные изменения затруднены или даже невозможны.
В некоторых локальных нишах маятник действительно качнется в сторону вылизывания кода, но в глобальном масштабе индустрии растут сами масштабы решаемых задач, а путей по развитию практически не видно. Распределенные системы уже уперлись в скорость света и фундаментальную плохую распараллеливаемость подавляющего большинства известных решений подавляющего большинства задач.
В случае прорыва в математике-алгоритмизации прогресс в вычислениях продолжиться, но фундаментально проблему может решить только прорыв в аппаратных технологиях, будь то квантовые сопроцессоры или компьютеры или еще что-нибудь…
P.S. В мобильных же технологиях главная проблема не столько вычислитель, сколько аккумулятор. Пока в них прогресса не будет качественные изменения затруднены или даже невозможны.
Ну не скажите, у нас, к примеру, код не прошедший code review просто не сольется в мастер. Для чего-то хоть сколько-то нового — архитектурное ревью. Целая куча тестеров и внутренние прогоны внутри компании, прежде чем выкладывать релиз. Или это по вашему не вылизывание?
sCrasher говорил про вылизывание производительности, Вы же говорите о внешнем виде и безбажности кода.
Производительность — это отдельная задача, которая ревью кода и архитектуры да QA-тестами не решается, а решается исследованиями этой самой производительности и эти исследования — отдельный самостоятельный процесс, только результаты которого попадут в описанную Вами цепочку.
Производительность — это отдельная задача, которая ревью кода и архитектуры да QA-тестами не решается, а решается исследованиями этой самой производительности и эти исследования — отдельный самостоятельный процесс, только результаты которого попадут в описанную Вами цепочку.
Не скажите, буквально неделю назад в ходе code review получил вопрос по тому, как изменения сказываются на производительности.
Скажите пожалуйста, а это единичный вопрос или у вас есть процесс по целенаправленному комплексному анализу производительности, а не только отдельных изменений кода?
На этот вопрос тяжело ответить однозначно. С одной стороны нет, с другой — почему бы и нет. Объясню подробнее.
1. В своем коде — да.
Мы наследуем принципы хромиума. Мы не допускаем изменений, которые:
* Значительно увеличивают размеры файлов (10Кб — уже значительно);
* Замедляют приложение даже на доли секунды;
* Значительно увеличивают потребление памяти;
2. В чужом коде — нет.
То что наш проект основан на хромиуме, дает нам хорошую базу и между тем немного связывает руки — чем радикальнее наши изменения, тем сложнее merge на новую версию. В общем целом, провести радикальное ревью мы не можем (директория с проектом на рабочем компе у меня сейчас занимает 82Гб — такие объемы очень тяжело отрефакторить, у нас пока маленькая команда, да и чем больше изменения, тем сложнее их отдать в апстрим.
3. Но местами — тоже да.
Но при этом нельзя сказать, что мы ничего не меняем и никого не слушаем, к примеру, вскоре после появления соседнего поста о уменьшении периода таймера хромом, кто-то предложил заняться этой проблемой и отдать в апстрим.
Обращаю внимание, что это ни в коем случае не официальная позиция. Это личные впечатления.
1. В своем коде — да.
Мы наследуем принципы хромиума. Мы не допускаем изменений, которые:
* Значительно увеличивают размеры файлов (10Кб — уже значительно);
* Замедляют приложение даже на доли секунды;
* Значительно увеличивают потребление памяти;
2. В чужом коде — нет.
То что наш проект основан на хромиуме, дает нам хорошую базу и между тем немного связывает руки — чем радикальнее наши изменения, тем сложнее merge на новую версию. В общем целом, провести радикальное ревью мы не можем (директория с проектом на рабочем компе у меня сейчас занимает 82Гб — такие объемы очень тяжело отрефакторить, у нас пока маленькая команда, да и чем больше изменения, тем сложнее их отдать в апстрим.
3. Но местами — тоже да.
Но при этом нельзя сказать, что мы ничего не меняем и никого не слушаем, к примеру, вскоре после появления соседнего поста о уменьшении периода таймера хромом, кто-то предложил заняться этой проблемой и отдать в апстрим.
Обращаю внимание, что это ни в коем случае не официальная позиция. Это личные впечатления.
Хабратопик проклят
Номер поста 186660. 18 это 3 по 6, то есть — 666, а после — деление на ноль… Действительно, конец близок.
Без унифицирования процедур и функций разных алгоритмических языков любое развитие алгоритма в «тормозной» среде — это начало «конца».
Вот чего-чего, а этот говнопост с техкранча увидеть на хабре не ожидал. Когда собираются умники и начинают вещать, что закону Мура конец, сингулярность по Курцвейлу отменяется… Детки, дядя Курцвейл знал и учитывал предстоящий буквальный конец закона Мура в своих прогнозах еще тогда, когда вы об этом законе слыхом не слыхали.
В отношении же безголовых разработчиков софта, которые считают выходом из проблемы дождаться нового проца со скоростью 10х, актуальнее вспоминать не закон Мура, а закон Мерфи. О том, что каким бы ни был софт, его всегда могут написать и напишут так, что он будет тормозить вне зависимости от скорости железа. Я когда-то поставил висту на погнанный C2Q с 4 гигами, думал уж на этом железе точно тормозить не будет. Фиг — эти тормоза от того, что кто-то кого-то бездумно ждет, а не потому что он так занят вычислительной работой. Мур тут не поможет — тут только морг поможет.
И это управляемый полунативный код .net, а что говорить о следующем уровне программной надстройки HTML? Это еще один дополнительный уровень геморроя и стремления разработчиков решать проблемы по закону Мерфи так, что никакой закон Мура им не поможет. Речь не о том, что сам тренд движения к решению прикладных задач внутри дополнительной контролируемой надстройки .net/Java/HTML5 выбран неверно, а что он предполагает ответственность всех сторон за производительность. Этот шаг делается в целом для извлечения максимальной пользы от закона Мура в глобальном масштабе — т. е. чтобы софт как таковой в мире мог выполнять все больше задач в самых разных сферах, для чего он как минимум кем-то должен быть написан — но вместе с тем это лишает отдельных разработчиков повода рассчитывать на ускорение со временем отдельно взятой софтины путем простого увеличения аппаратной мощности.
Это не конец закона Мура — это просто конец индивидуальной ответственности разработчика за скорость работы софтины, переход к такой парадигме разработки, где глобальная взаимосвязанность и универсальность важнее локальной скорости. То есть если ты начинаешь писать под хтмл5, то нужно учитывать весь нижележащий стек. И на хтмл5 не напишешь майнер биткойна — для этого лучше не то что нативное, а вообще аппаратное решение. Вот куда уходит закон Мура и вот почему нельзя считать его универсальным рецептом для исправления косяков сидящих в комфортных фреймворках прикладных веб-разработчиков. Даже для нативщиков в свое время не так все было просто — а эти привыкли, что дядя Мур все сделает за них. Фигушки. Наиболее впечатляющая закономерность развития в современном мире — не для криворуких, это инструмент для умных людей. В чем-то они напоминают особо клинических фэнбоев сингулярности, обчитавшихся Никитина и обитающих на соответствующем форуме. Те тоже думают, что они автоматически, ничего не делая, станут недосягаемой вершиной эволюции и на всех остальных навсегда забьют болт, потому что они где-то увидели опережающий рост отдельного параметра. А фиг вам, двигать прогресс — это значит думать и придумывать решения, а не откинуться на спинку кресла, пока тебя оттуда в шею выгонит разработанный другими бот.
В отношении же безголовых разработчиков софта, которые считают выходом из проблемы дождаться нового проца со скоростью 10х, актуальнее вспоминать не закон Мура, а закон Мерфи. О том, что каким бы ни был софт, его всегда могут написать и напишут так, что он будет тормозить вне зависимости от скорости железа. Я когда-то поставил висту на погнанный C2Q с 4 гигами, думал уж на этом железе точно тормозить не будет. Фиг — эти тормоза от того, что кто-то кого-то бездумно ждет, а не потому что он так занят вычислительной работой. Мур тут не поможет — тут только морг поможет.
И это управляемый полунативный код .net, а что говорить о следующем уровне программной надстройки HTML? Это еще один дополнительный уровень геморроя и стремления разработчиков решать проблемы по закону Мерфи так, что никакой закон Мура им не поможет. Речь не о том, что сам тренд движения к решению прикладных задач внутри дополнительной контролируемой надстройки .net/Java/HTML5 выбран неверно, а что он предполагает ответственность всех сторон за производительность. Этот шаг делается в целом для извлечения максимальной пользы от закона Мура в глобальном масштабе — т. е. чтобы софт как таковой в мире мог выполнять все больше задач в самых разных сферах, для чего он как минимум кем-то должен быть написан — но вместе с тем это лишает отдельных разработчиков повода рассчитывать на ускорение со временем отдельно взятой софтины путем простого увеличения аппаратной мощности.
Это не конец закона Мура — это просто конец индивидуальной ответственности разработчика за скорость работы софтины, переход к такой парадигме разработки, где глобальная взаимосвязанность и универсальность важнее локальной скорости. То есть если ты начинаешь писать под хтмл5, то нужно учитывать весь нижележащий стек. И на хтмл5 не напишешь майнер биткойна — для этого лучше не то что нативное, а вообще аппаратное решение. Вот куда уходит закон Мура и вот почему нельзя считать его универсальным рецептом для исправления косяков сидящих в комфортных фреймворках прикладных веб-разработчиков. Даже для нативщиков в свое время не так все было просто — а эти привыкли, что дядя Мур все сделает за них. Фигушки. Наиболее впечатляющая закономерность развития в современном мире — не для криворуких, это инструмент для умных людей. В чем-то они напоминают особо клинических фэнбоев сингулярности, обчитавшихся Никитина и обитающих на соответствующем форуме. Те тоже думают, что они автоматически, ничего не делая, станут недосягаемой вершиной эволюции и на всех остальных навсегда забьют болт, потому что они где-то увидели опережающий рост отдельного параметра. А фиг вам, двигать прогресс — это значит думать и придумывать решения, а не откинуться на спинку кресла, пока тебя оттуда в шею выгонит разработанный другими бот.
Программисты не всегда безголовые. Мир меняется, и сегодня решаются сложные задачи нового уровня. Вот напишите gmail, dropbox или facebook на ассемблере. За те же сроки, как стартапили эти проекты. И развивайте его, конкурируйте, поддерживайте. Я бы посмотрел на результат.
Аппаратное, ассемблер, с++, JS — все найдет свою нишу. Это нормально. Если кто-то напишет майнер на JS — туда ему и дорога. Не используйте такой майнер. Если вдруг все напишут майнейры только на JS, то тут стоит задуматься — может так и надо? :) Может так выгоднее в итоге всем? По крайней мере, не нужно будет фиксить баг паяльником.
По поводу сабжа. Любовь программистов к ожиданию аппаратного прогресса никуда не денется. Нас ждет параллелизм и языки нового уровня, и все пойдет по новой. Рост будет продолжаться еще долго, и только потом потребуется новый скачок на новый уровень, но что-то мне подсказывает, что снова речь пойдет вовсе не об оптимизации старого.
Аппаратное, ассемблер, с++, JS — все найдет свою нишу. Это нормально. Если кто-то напишет майнер на JS — туда ему и дорога. Не используйте такой майнер. Если вдруг все напишут майнейры только на JS, то тут стоит задуматься — может так и надо? :) Может так выгоднее в итоге всем? По крайней мере, не нужно будет фиксить баг паяльником.
По поводу сабжа. Любовь программистов к ожиданию аппаратного прогресса никуда не денется. Нас ждет параллелизм и языки нового уровня, и все пойдет по новой. Рост будет продолжаться еще долго, и только потом потребуется новый скачок на новый уровень, но что-то мне подсказывает, что снова речь пойдет вовсе не об оптимизации старого.
Не нужно писать gmail, dropbox или facebook на ассемблере. Речь не о том, что навороченные высокоуровневые фреймворки не нужны, или что их пишут сплошь безголовые идиоты. Речь о том, что они сами по себе являются не менее сложной технологией, чем то железо, на которых они работают, и поэтому рост производительности нового железа еще не гарантируют, что старый софт на нем будет работать пропорционально быстрее. Софт — отдельное направление технологий, которое нужно совершенствовать параллельно с железом. Был когда-то показательный пример, взяли какой-то алгоритм сортировки 1977 года и прогнали на маке 2007 г. выпуска, и наоборот — алгоритм 2007 на древнем маке. Последний оказался быстрее, несмотря на очевидный прогресс закона Мура. Разумеется, ускорить так можно не всякий алгоритм, есть фундаментальные математические ограничения. Но если брать не отдельный алгоритм, а комплексную распределенную задачу, типа построения социальной сети, для совершенствования архитектур там непочатый край работы. И чем сложнее задача, тем меньше шансов, что ее существенно ускорит улучшение показателей отдельно взятого компонента пусть даже в 2 раза — будь он железный или программный. Тот же пример с параллелизмом — это означает необходимость коренной переделки алгоритмов и архитектур. Я ни в коей мере не отрицаю, что на этом пути будут достигнуты значительные успехи; я просто указываю на то, что зависит это от усилий всего сообщества разработчиков стека технологий, а не от одних только производителей процессоров или еще какого-либо железа.
P.S. Управляемый код (Java, JS, .NET) — это все не так медленно, как может показаться. Разработчики сред выполнения не спят ночами, приводя их скорость максимально близко к нативному коду. И это прекрасно, что мы можем писать, управляя разработкой проще, если результат по скорости не сильно отличается от идеального. Весь сложный стек низких уровней допиливается по необходимости, когда петух клюнет. JS существует очень давно, а за его разгон взялись относительно недавно. Так что я не удивлюсь даже «майнерам» в веб-исполнении через N лет.
Тормоза происходят не от управляемого кода, а от сборщика мусора и работы с памятью в этих песочницах.
Причём если в C# всё достаточно шикарно, можно даже напрямую к нативной памяти обращаться, если в Java всё более-менее неплохо, то в JS наблюдается просто лютый кошмар.
У программиста нет ни малейшей возможности не то что повлиять на работу сборщика мусора и аллокатора памяти, но даже хоть как-то учесть её при оптимизации приложения, т.к. не существует никакого стандарта, никакой документации, и даже профайлеры (довольно хреновые, к слову) в браузерах появились совсем недавно.
Вот и выходит, что JS зачастую тормозит на ровном месте, когда вдруг оказывается, что на неудачно оформленном цикле некоторые браузеры внезапно отъедают до 400Мб памяти, а по окончании цикла идёт 2 секунды фриза, т.к. вся эта память начинает высвобождаться…
В статье по ссылке выше как раз говорится, что скорость работы таких песочниц повышается с увеличением количества доступной оперативки, а скорость процессора там и так по-максимуму задействована. Т.е. если в мобильных устройствах удастся увеличить объём оперативки до 8Гб (а лучше больше), вся эта тормознутость вдруг покажет вполне приличные результаты, даже если не увеличивать мощность процессора и количество ядер.
Проблема лишь в том, что по невыясненной причине (косяк инженеров?) память интегрирована внутрь ARM, т.е. просто так взять и поставить побольше невозможно — сразу начинаются сложности с площадью кристалла, охлаждением, компоновкой и т.д.
Причём если в C# всё достаточно шикарно, можно даже напрямую к нативной памяти обращаться, если в Java всё более-менее неплохо, то в JS наблюдается просто лютый кошмар.
У программиста нет ни малейшей возможности не то что повлиять на работу сборщика мусора и аллокатора памяти, но даже хоть как-то учесть её при оптимизации приложения, т.к. не существует никакого стандарта, никакой документации, и даже профайлеры (довольно хреновые, к слову) в браузерах появились совсем недавно.
Вот и выходит, что JS зачастую тормозит на ровном месте, когда вдруг оказывается, что на неудачно оформленном цикле некоторые браузеры внезапно отъедают до 400Мб памяти, а по окончании цикла идёт 2 секунды фриза, т.к. вся эта память начинает высвобождаться…
В статье по ссылке выше как раз говорится, что скорость работы таких песочниц повышается с увеличением количества доступной оперативки, а скорость процессора там и так по-максимуму задействована. Т.е. если в мобильных устройствах удастся увеличить объём оперативки до 8Гб (а лучше больше), вся эта тормознутость вдруг покажет вполне приличные результаты, даже если не увеличивать мощность процессора и количество ядер.
Проблема лишь в том, что по невыясненной причине (косяк инженеров?) память интегрирована внутрь ARM, т.е. просто так взять и поставить побольше невозможно — сразу начинаются сложности с площадью кристалла, охлаждением, компоновкой и т.д.
Ничего там не интегрироано, package over package — это просто бутерброд из чипов. Да и микросхемы высокой плотности, вроде бы, есть. Вот только DDR — DRAM. И ее нужно обновлять. Постоянно. И если процессор можно выключить в фоне — то память нет.
Но, справедливости ради, следует отметить, что в моем призыве по «сборке мусора», я обрел хорошую компанию в лице самого бога программирования — Джона Кармака
Не надо причислять здесь Джона Кармака. Смотрим ваше сообщение:
пишет Кармак: «Но я также уверен, что HTML5 не может быть подходящим решениям для любого действительно нетривиального IOS приложения ни сейчас, ни в ближайшие годы; это положение мне кажется верным и для других мобильных ОС».
Идем по ссылке и смотрим оригинал:
Good article: sealedabstract.com/rants/why-mobile-web-apps-are-slow/ … I tend to think that garbage collection in some contexts even for games is justified on big platforms.
Что в переводе звучит совсем по другому:
Хорошая статья: sealedabstract.com/rants/why-mobile-web-apps-are-slow/… Я склоняюсь к мысли, что сборка мусора в некоторых контекстах, даже для игр, является оправданной на больших платформах.
Судя по контексту о мобильных веб приложениях, речь идет именно о сборке мусора в этих самых веб приложениях
Не надо причислять здесь Джона Кармака. Смотрим ваше сообщение:
пишет Кармак: «Но я также уверен, что HTML5 не может быть подходящим решениям для любого действительно нетривиального IOS приложения ни сейчас, ни в ближайшие годы; это положение мне кажется верным и для других мобильных ОС».
Идем по ссылке и смотрим оригинал:
Good article: sealedabstract.com/rants/why-mobile-web-apps-are-slow/ … I tend to think that garbage collection in some contexts even for games is justified on big platforms.
Что в переводе звучит совсем по другому:
Хорошая статья: sealedabstract.com/rants/why-mobile-web-apps-are-slow/… Я склоняюсь к мысли, что сборка мусора в некоторых контекстах, даже для игр, является оправданной на больших платформах.
Судя по контексту о мобильных веб приложениях, речь идет именно о сборке мусора в этих самых веб приложениях
Дело же не в сборке мусора. Сравните хотя бы производительность HTML5-игр, написанных на JS, и игр на C# под Unity.
В Unity вовсе не JS, там UnityScript, который JS напоминает лишь издалека, если приглядеться. В UnityScript отсутствует множество чисто динамических возможностей JS, а также можно использовать статическую типизацию. Это значительно упрощает компиляцию и выполнение скриптов на UnityScript по сравнению с JS.
Сначала мобильные приложения в большинстве своем адски тормозили (прекрасный пример — лаги в интерфейсе Android, сохраняющиеся, даже когда сменились несколько мобильных процессоров). Но все больше и больше разработчиков (google в пример) постоянно оптимизируют их. Возможно, из тех-же соображений, что доносит нам эта статья, об оптимизации стали задумываться многие. Почему? Да из-за тех же рекомендаций, что и при создании веб-сайтов: веб-сайт открывается быстрее — посетитель с большей долей вероятности задержится на нем. Быстрые приложения вытесняют медленные.
Так что, мне кажется, все хорошо!
Так что, мне кажется, все хорошо!
Перестанут расти мощности — будем по-новой учиться писать оптимальный код, как когда-то умели. Сейчас благодаря мощностям процессоров во главу угла ставят читаемость, портируемость, простоту и максимальное использование внешних фреймворков. Что закономерно привело к ситуации, когда Word, выполняющий ровно те же функции что и 20 лет назад, требует в 100 раз более мощной машины.
Тут скорее проблема не в том, что тот же ворд требует более мощной машины, а что в 100 раз более мощная машина, превышающая все мощности NASA на момент запуска Apollo, используется в основном для того же ворда и незначительных усовершенствований ОС. Что начало тормозить спрос на новые ПК и опосредованно — процесс разработки железа той же Intel. В 2003-2007 тот же ворд достиг настолько приемлемого качества, что до сих пор используется в качестве стандарта большинством юзеров, а иные вообще перешли на Google Docs. И поднялся вопрос, а зачем апгрейдить софт, а следовательно и железо теми же темпами, которые были характерны для времен их куда более заметной бажности и тормознутости. С другой стороны, спрос на чистые терафлопсы в последнее время начал удовлетворяться облачными решениями — а это опять же тормоз для эволюции ПК. В итоге ПК из авангарда прогресса бизнес-вычислений начал прекращаться в некое полустатичное клиентское устройство, фактически терминал, с сохранением всей периферии и ее оффлайн-функций, но без особых темпов роста количественных показателей (кроме памяти, которая все больше диверсифицируется по типам и назначению). Фактически сегодня ПК все чаще апгрейдят из-за качественных недостатков — отсутствия такой-то функции в железе или его банального физического износа, а моральное устаревание характерно больше для 5-7-летнего периода, а не 1,5-2, как когда-то.
Но за закон Мура и его преемника я спокоен — спрос на них не тормозится, в отличие от спроса на гигагерцы ПК среди большинства бизнес-пользователей, а растет за счет опережающего роста данных, которые нужно обрабатывать. Например, генетических — вот показательная аналитика о том, что на данный момент является самым узким местом прогресса секвенирования, и это — ИТ. «Поздравляю»… Но это также говорит о том, что деньги в следующие качественные поколения ИТ-железа — с фокусом уже не на ПК, а на обработку данных — пойдут не менее активно, чем когда-то в доПКшные технологии.
www.kurzweilai.net/dna-data-overload
releases.jhu.edu/2013/07/12/solving-dna-puzzles-is-overwhelming-computer-systems-researchers-warn/
Но за закон Мура и его преемника я спокоен — спрос на них не тормозится, в отличие от спроса на гигагерцы ПК среди большинства бизнес-пользователей, а растет за счет опережающего роста данных, которые нужно обрабатывать. Например, генетических — вот показательная аналитика о том, что на данный момент является самым узким местом прогресса секвенирования, и это — ИТ. «Поздравляю»… Но это также говорит о том, что деньги в следующие качественные поколения ИТ-железа — с фокусом уже не на ПК, а на обработку данных — пойдут не менее активно, чем когда-то в доПКшные технологии.
www.kurzweilai.net/dna-data-overload
releases.jhu.edu/2013/07/12/solving-dna-puzzles-is-overwhelming-computer-systems-researchers-warn/
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Ваше приложение медленное? Это потому, что наша цивилизация гибнет