Процессоры становятся быстрее. Просто гонка пошла не в частоту, а в новые инстркуции, в количество ядер.
Все это, просто судороги умирающего закона Мура. Недолго продлятся.
Вы же должны понимать, что удобство разработки, скорость разработки, и вовремя исправленная уязвимость — это тоже высокая производительность,
Так, да не так. Потому что суммарное время выполнения программы намного выше чем время разработки (а если наоборот, то такую программу и обсуждать не стоит). Поэтому стоит поработать немножко больше, экономя время потребителей.
Да, понятно что время разработки, оно ближе к телу разработчика, а время выполнения — оно там, при потребителей случается. Куда они денутся? Подождут немножко. А программа загружается 30 секунд? Ничего, пусть не закрывают. А ждать приходится сто раз, пока откроется окно — ерунда, вот у меня стоит супер-пупер-зверь машина и у меня не тормозит. Пусть они купят еще 32GB RAM и все будет ОК.
А вот, возьмут и уйдут там, где их время не разбрасывают и ценят.
А между прочем, время разработки на ассемблере не так и большое. Посмотрите на мой проект форума (ссылка наверх) — зайдите в хранилище кода и посмотрите сколько время оно мне заняло. Оно не так уж и большое.
Время исправления багов и уязвимостей также намного ниже ожидаемого. (кстати, уязвимости в ассемблерном коде почти и нет, потому что он проще и чище)
Поглядите немножко на исходниках — там все читается просто и понятно.
У него интерес. Он же компиляторы на C++ и D разрабатывает. Конечно что так говорит будет.
Но кстати, если разработка ведется на C или C++, то наверное проблема несколько легче. Но когда такое начинают говорить программисты на всякие Питоны, тогда звучит и правда смешно.
А вот и нет. Это вообще-то устарелое мышление. В нулевых годах так и было, когда прогресс в железе шел быстрым ходом и софт не успевал за ним, а новые процессоры исправляли медленный софт очень быстро.
Те времена прошли. Были, да сплыли. Теперь процессоры уже не станут быстрее. А потребители хотят чтобы софт становился лучше. Чтобы не ждать все время и чтобы программы не висли и результат давали, ну вот сейчас.
Параллельные алгоритмы и многоядерные процессоры дадут некоторое время на перегруппировку, но далеко не все алгоритмы работают параллельно.
Ну, почему сразу "вовсе"? Конечно, немножко придется подкоректировать исходники, но общая канва программы будет та же самая и вполне заработает например в Линукс.
А программы написанные на Си (без вставок на асме) — будут работать, только перекомпилировать надо
Ну, это вряд ли. Работать будут только очень, очень простые программы. И те, которые изначально писались чтобы были 100% переносимые. А это наверное 3% от всех сишних программ. И даже те, вряд ли можно перекомпилировать просто так на современных компиляторов.
А я на ассемблере пишу уже около 30 лет. И программы написаны примерно в 1987-ом, все еще работают нормально. Правда, они под ДОС, но что поделать, ни Линукс ни Windows тогда не было.
А вообще, каждая программа нуждается в поддержке. И на C/C++ и на ассемблере. Компиляторы меняются, стандарты языка меняются. И заметьте, они меняются намного быстрее, чем процессоры. Так что, через 10 лет, программа на C/C++ тоже вполне вероятно не скомпилируется сразу, а понадобиться пошаманить над исходниками.
Все оптимизации в языках высокого уровня (C это ЯВУ) сводятся до "давайте сделаем это на ассемблере и придумаем как обмануть компилятора, чтобы генерировал наш код".
А почему? Компилятор, он не священная корова. Зачем нам посредник в общением с богом процессором? Написать все на ассемблере и все дела. Я именно так и делаю. Код получается не хуже чем на C, а иногда даже лучше. Вот отзыв одного удивленного программиста после просмотра моего ассемблерного кода (кстати веб приложение):
Just had a cursory peek at the source code. What struck me most strongly is that the number of LOC that are not direct calls to Sqlite is quite low, the overall size of the project is very small, and that it's remarkably easy to work out what the code actually does.
Где прочитать не могу сказать. Сам читал в сети, только ссылки не сохранял.
Саморазряд очень трудно сделать 1% в сутки для стационарного маховика (для мобильного и подавно). И не из за трения, а из за гироскопического момента. Дело в том, что магнитная подвеска удерживает только вес маховика, а радиальные нагрузки (если раскачать маховика например) берут на себя обычные подшипники. А ведь земля вращается и маховик с ней. Из за гироскопического момента, все время на ось гироскопа будет действовать радиальная нагрузка и соответственно трение в подшипниках и потери энергии.
Лечение этого эффекта просто — подвеска маховика в карданных подвесов, точно как гирокомпасах. Только это решение усложняет и увеличивает конструкцию агрегата настолько, что делает такое решение совершенно нереальным. (И увеличивает объем маховика от R^2 до R^3.)
Так что, пока супермаховики используют только там где нужно очень быстрое заряжении, недолгое хранение и гигантские мощности. Например фирма Beacon Power делает устройства для выравнивание суточной неоднородности в потреблении. Российская компания Kinetic Power, вместе с професором Гулиа Н.В., вроде тоже производит (проектирует?) нечто подобное.
Это зависит от того, как будем заряжать супермаховик. Если электричеством из АЭС, то цена будет одна, если от ГЭС, то другая, а если от дизеля, то третья.
Но то же самое в силе и у топливных элементов. В них можно сжигать водород, метан, метанол, цинк, алюминий. И стоимость каждый раз будет своя.
Не Земле, вся энергия берется из аккумуляторов. Энергия нефти, это аккумулированная очень давно энергия солнца. Энергия биогаза, тоже энергия солнца, только аккумулирована она недавно. Энергия АЭС, это энергия сверхновой звездой которая была раньше солнца. Только термоядерных реакции можно рассматривать как первичных, да и то, можно считать, что это аккумулированная энергия большого взрыва.
Все это, просто судороги умирающего закона Мура. Недолго продлятся.
Так, да не так. Потому что суммарное время выполнения программы намного выше чем время разработки (а если наоборот, то такую программу и обсуждать не стоит). Поэтому стоит поработать немножко больше, экономя время потребителей.
Да, понятно что время разработки, оно ближе к телу разработчика, а время выполнения — оно там, при потребителей случается. Куда они денутся? Подождут немножко. А программа загружается 30 секунд? Ничего, пусть не закрывают. А ждать приходится сто раз, пока откроется окно — ерунда, вот у меня стоит супер-пупер-зверь машина и у меня не тормозит. Пусть они купят еще 32GB RAM и все будет ОК.
А вот, возьмут и уйдут там, где их время не разбрасывают и ценят.
А между прочем, время разработки на ассемблере не так и большое. Посмотрите на мой проект форума (ссылка наверх) — зайдите в хранилище кода и посмотрите сколько время оно мне заняло. Оно не так уж и большое.
Время исправления багов и уязвимостей также намного ниже ожидаемого. (кстати, уязвимости в ассемблерном коде почти и нет, потому что он проще и чище)
Поглядите немножко на исходниках — там все читается просто и понятно.
Не так страшен черт как его малюют. :)
Я тоже не уверен. Давайте разберемся… В конце концов, я программы на ассемблере пишу постоянно и публикую в сети:
Вот — IDE для FASM на ассемблере. Сам сайт сделан на CMS на ассемблере. А еще есть у меня высокопроизводительный форум на ассемблере.
А можно чего нибудь вашего посмотреть, чтобы было на ассемблере?
Ну, я вообще то, в деда Мороза верю. :D
Это что? Argumentum ad verecundiam?
У него интерес. Он же компиляторы на C++ и D разрабатывает. Конечно что так говорит будет.
Но кстати, если разработка ведется на C или C++, то наверное проблема несколько легче. Но когда такое начинают говорить программисты на всякие Питоны, тогда звучит и правда смешно.
А вот и нет. Это вообще-то устарелое мышление. В нулевых годах так и было, когда прогресс в железе шел быстрым ходом и софт не успевал за ним, а новые процессоры исправляли медленный софт очень быстро.
Те времена прошли. Были, да сплыли. Теперь процессоры уже не станут быстрее. А потребители хотят чтобы софт становился лучше. Чтобы не ждать все время и чтобы программы не висли и результат давали, ну вот сейчас.
Параллельные алгоритмы и многоядерные процессоры дадут некоторое время на перегруппировку, но далеко не все алгоритмы работают параллельно.
Так что учите ассемблер. Пригодится.
Уже.
Так он и на ARM не пойдет. Просто надо написать ту самую программу для ARM. И будут нам всем две отличные программы, наместо одну посредственную.
Ну, почему сразу "вовсе"? Конечно, немножко придется подкоректировать исходники, но общая канва программы будет та же самая и вполне заработает например в Линукс.
Ну, это вряд ли. Работать будут только очень, очень простые программы. И те, которые изначально писались чтобы были 100% переносимые. А это наверное 3% от всех сишних программ. И даже те, вряд ли можно перекомпилировать просто так на современных компиляторов.
А я на ассемблере пишу уже около 30 лет. И программы написаны примерно в 1987-ом, все еще работают нормально. Правда, они под ДОС, но что поделать, ни Линукс ни Windows тогда не было.
А вообще, каждая программа нуждается в поддержке. И на C/C++ и на ассемблере. Компиляторы меняются, стандарты языка меняются. И заметьте, они меняются намного быстрее, чем процессоры. Так что, через 10 лет, программа на C/C++ тоже вполне вероятно не скомпилируется сразу, а понадобиться пошаманить над исходниками.
Все это может быть только если быстродействие компьютеров повышается быстрее, чем сложность программ, которые на них выполняются.
А закон Мура уже не действует. Откуда лишней производительности взяться?
Некоторые даже считают что In 9 years Assembler will return to mainstream.
Все оптимизации в языках высокого уровня (C это ЯВУ) сводятся до "давайте сделаем это на ассемблере и придумаем как обмануть компилятора, чтобы генерировал наш код".
А почему? Компилятор, он не священная корова. Зачем нам посредник в общением с
богомпроцессором? Написать все на ассемблере и все дела. Я именно так и делаю. Код получается не хуже чем на C, а иногда даже лучше. Вот отзыв одного удивленного программиста после просмотра моего ассемблерного кода (кстати веб приложение):Где прочитать не могу сказать. Сам читал в сети, только ссылки не сохранял.
Саморазряд очень трудно сделать 1% в сутки для стационарного маховика (для мобильного и подавно). И не из за трения, а из за гироскопического момента. Дело в том, что магнитная подвеска удерживает только вес маховика, а радиальные нагрузки (если раскачать маховика например) берут на себя обычные подшипники. А ведь земля вращается и маховик с ней. Из за гироскопического момента, все время на ось гироскопа будет действовать радиальная нагрузка и соответственно трение в подшипниках и потери энергии.
Лечение этого эффекта просто — подвеска маховика в карданных подвесов, точно как гирокомпасах. Только это решение усложняет и увеличивает конструкцию агрегата настолько, что делает такое решение совершенно нереальным. (И увеличивает объем маховика от R^2 до R^3.)
Так что, пока супермаховики используют только там где нужно очень быстрое заряжении, недолгое хранение и гигантские мощности. Например фирма Beacon Power делает устройства для выравнивание суточной неоднородности в потреблении. Российская компания Kinetic Power, вместе с професором Гулиа Н.В., вроде тоже производит (проектирует?) нечто подобное.
Биотопливо не так дешевое, как принято считать. И оно не дешевле электричества из АЭС и тем более из ГЭС.
Я неслучайно спрашивал откуда они берут биогаз. А то в статье только красиво сверкающие кубики топливных элементов показано.
Это зависит от того, как будем заряжать супермаховик. Если электричеством из АЭС, то цена будет одна, если от ГЭС, то другая, а если от дизеля, то третья.
Но то же самое в силе и у топливных элементов. В них можно сжигать водород, метан, метанол, цинк, алюминий. И стоимость каждый раз будет своя.
Как это так не верну? Очень даже. Нужна просто лампочка, запитанная от дизельного генератора.
Я просто комментирую ваш бред, насчет супермаховиков, которые ничуть не хуже и не лучше топливных элементов, о которых статья.