[Вынесено из ветки С--

Автор: remark
Дата: 07.07.08

]

Здравствуйте, eao197, Вы писали:

E>Поэтому количество ниш, в которых C++ был бы действительно стоящим выбором (как раз потому, что позволяет работать как на низком, так и на высоком уровне) сокращается и, надо полагать, будет сокращаться. И это нормально, хотя и неприятно для тех, кто привык работать на C++.


Тут, кстати, намечаются интересные сдвиги. 40 лет мы получали Дивиденты Мура в виде увеличивающейся на 40-50% в год производительности процессоров. Дивиденты эти постоянно растрачивались вместе с получением новых. На что же они были растрачены? Значительная часть ушла на новые фичи и улучшение старых фич, а так же на увеличение обрабатываемых объемов данных. Сбавлять темпа растраты в этом направлении не понятно куда — пользователи не только привыкли к "крутым" фичам, но они так же и привыкли к тому, что новые фичи постоянно добавляются, а старые — улучшаются. Другая значительная часть дивидентов ушла на практики "быстрой разработки", архитектуру ПО, бесчисленные уровни абстракции, новые "безопасные" языки и т.д. В этом направлении "откатываться" тоже особо не куда.
Однако сейчас "структура" дивидентов меняется. Частота процессоров будет расти по оптимистическим прогнозам на 10-15% в год, основные же дивиденты будут в виде увеличивающегося параллелизма в процессорах. Как тратить частоту процессоров на фичи и на уровни абстракции мы научились, как тратить параллелизм на фичи и на уровни абстракции пока не понятно. Очевидным образом параллелизм тратиться только на задачи врожденно параллельные по данным (обработка видео), и на врожденно независимые задачи (обработка множества запросов сервером). Хотя и тут надо научиться это делать, иметь библиотека поддержки, и в конце-концов просто делать это.
Допустим возьмем Java. В 2000 году она была очень медленной. Сейчас она вполне быстрая и для десктоп приложений. Однако если взять Ruby, то если сейчас он медленный, и через 8 лет он будет примерно такой же медленный. Как тратить параллелизм на динамическую типизацию и интерпретацию языка не видится.
Все сообщество разработки ПО привыкло именно к увеличению частоты процессоров. Сейчас это такая неявная аксиома. На которую мы полагаемся, когда, например, программисты и тестировщики работают на самых передовых компьютерах, а когда продукт выходит, уже вроде и средние компьютеры подтягиваются к этой производительности. Или когда мы безусловно предполагаем, что в следующем релизе мы сможем добавить ещё X фич в продукт.

Первый (на первый взгляд противоестественный) вывод отсюда, что параллелизм усилит потребность в средствах "однопоточной" оптимизации производительности. И вообще в том, что может давать хорошую "однопоточную" производительность, т.к. не всё можно распараллелить, а фичи-то добавлять надо, и объемы данных растут.
Второй — то, что разработчикам ПО надо будет учиться "делать больше, имея меньше". Допустим к подсветке синтаксиса хотим добавить автодополнение, значит либо надо выкинуть что-то старое, либо подсветку синтаксиса надо сделать в 2 раза быстрее, т.к. к следующему релизу компьютеры магически не станут в 2 раза быстрее.


И тут ещё второй момент незаметно подкрался с другой стороны. Это всякие Flash Hard Drive, Solid State Drive и Hybrid Hard Drive. Уже сейчас они обеспечивают время доступа более чем в 100 меньшее, чем традиционные HDD. И уже на заре их развития, а развиваться им (в отличие от HDD) ещё есть куда. Очевидно их будущее применение для серверов, уже сейчас HP выпускает такие сервера.
Какое это имеет отношение к делу? Сейчас диск является одним их наиболее медленных компонент компьютера (даже сеть быстрее, в основном из-за латентности). Соотв. нормальная ситуация, что производительность системы упирается в диск с запасом в 10 раз. Что будет, если время доступа к диску снизится в 100 раз? Правильно, производительность системы начнет упираться в процессор с запасом в 10 раз. Выводы отсюда достаточно просты и прозрачны.


Этим всем я, конечно, не хочу сказать, что сообщество вернётся к ассемблеру. Это не возможно, точка невозврата уже пройдена. Но тем не менее, для *некоторых* типов приложений эти тренды будут иметь место.