Здравствуйте, 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 раз. Выводы отсюда достаточно просты и прозрачны.
Этим всем я, конечно, не хочу сказать, что сообщество вернётся к ассемблеру. Это не возможно, точка невозврата уже пройдена. Но тем не менее, для *некоторых* типов приложений эти тренды будут иметь место.
Здравствуйте, remark, Вы писали:
R>Какое это имеет отношение к делу? Сейчас диск является одним их наиболее медленных компонент компьютера (даже сеть быстрее, в основном из-за латентности). Соотв. нормальная ситуация, что производительность системы упирается в диск с запасом в 10 раз. Что будет, если время доступа к диску снизится в 100 раз? Правильно, производительность системы начнет упираться в процессор с запасом в 10 раз. Выводы отсюда достаточно просты и прозрачны.
???
самой непроизводительной частью компьютера является человек. он слишком медленно и печатает и соображает.
производительность диска практически не влияет на производительность программы в обычной ситуации, поскольку диск является лишь устройством хранения. если вы намекаете, что диск будете использовать как озу, то лучше просто увеличить озу.
R>Этим всем я, конечно, не хочу сказать, что сообщество вернётся к ассемблеру. Это не возможно, точка невозврата уже пройдена. Но тем не менее, для *некоторых* типов приложений эти тренды будут иметь место.
почему при констатации факта, что РОСТ производительности замедлился, возбуждается какая-то паника, что пора откатываться назад??? ваши сегодняшние задачи работать будут. откатываться никуда не надо. рыть землянку, затариваясь сахаром, спичками и солью — не стоит.
R>
Красиво написано, но.... Сильно вы преувеличиваете роль тактовой частоты процессоров в общем быстродействии компьютеров, вернее выполняемых программ.
Почти всегда тормоза моего компа были связаны с недостатком памяти.
Процессор нужен для чисто вычислительных задач, но они чаще всего отлично распараллеливаются.
Здравствуйте, merk, Вы писали:
M>производительность диска практически не влияет на производительность программы в обычной ситуации, поскольку диск является лишь устройством хранения. если вы намекаете, что диск будете использовать как озу, то лучше просто увеличить озу.
До 100Гб? До пары террабайт?
Для меня вот "обычная ситуация" — работа с базами данных. Не кардинально гигантскими, но в ОЗУ ну никак не влезают...
А сервер БД от ускорения дисков может получить колоссальный выигрыш.
Здравствуйте, fmiracle, Вы писали:
F>Здравствуйте, merk, Вы писали:
M>>производительность диска практически не влияет на производительность программы в обычной ситуации, поскольку диск является лишь устройством хранения. если вы намекаете, что диск будете использовать как озу, то лучше просто увеличить озу.
F>До 100Гб? До пары террабайт? F>Для меня вот "обычная ситуация" — работа с базами данных. Не кардинально гигантскими, но в ОЗУ ну никак не влезают... F>А сервер БД от ускорения дисков может получить колоссальный выигрыш.
высоконагруженные серверы бд, стоят особняком. но иного применения тут и не придумаешь.
100гб им конечно мало, но терабайта-двух уже досточно.
но это очень особенные сверхцентрализованные приложения, не всякая коропоративная бд имеет такие нагрузки.
я этот случай ввиду не имел.
Здравствуйте, remark, Вы писали:
R>Тут, кстати, намечаются интересные сдвиги. 40 лет мы получали Дивиденты Мура в виде увеличивающейся на 40-50% в год производительности процессоров. Дивиденты эти постоянно растрачивались вместе с получением новых. На что же они были растрачены? Значительная часть ушла на новые фичи и улучшение старых фич, а так же на увеличение обрабатываемых объемов данных. Сбавлять темпа растраты в этом направлении не понятно куда — пользователи не только привыкли к "крутым" фичам, но они так же и привыкли к тому, что новые фичи постоянно добавляются, а старые — улучшаются.
Это само собой, но вот у реализации этих самых фич качество и оптимальность кода порой явно не на высоте. Я совершенно уверен, что многое из того, что сейчас сущетсвует, мы бы имели все равно, если бы лет 5 назад рост производительности компьютеров вообще прекратился бы. Не все, конечно, но многое. Просто писали бы эти фичи, исходя из того, что есть, а не в надежде на то, что будет. И пооптимальнее написали бы.
>Другая значительная часть дивидентов ушла на практики "быстрой разработки", архитектуру ПО, бесчисленные уровни абстракции, новые "безопасные" языки и т.д. В этом направлении "откатываться" тоже особо не куда.
Черт знает. Отката, скорее всего, не будет, верно, но вот оптимизация того, что есть — вполне возможна.
А вообще все определяться будет развитием аппаратуры. Если узким звеном будет диск — ничего мы не получим, это нам почти не подвластно. Если же узким звеном будет процессор(ы) — то раньше или позже найдется кто-то, кто пошлет к чертовой матери все бесчисленные уровни абстракции и напишет продукт... нет, не на ассемблере, конечно, но такими средствами, котоорые позволят выжать из этого процессора(ов) все, что он(и) могут и не тратить это на всякую ерунду, а только по существу дела. Свято место пусто не бывает.
R>Первый (на первый взгляд противоестественный) вывод отсюда, что параллелизм усилит потребность в средствах "однопоточной" оптимизации производительности. И вообще в том, что может давать хорошую "однопоточную" производительность, т.к. не всё можно распараллелить, а фичи-то добавлять надо, и объемы данных растут.
Не вижу тут ничего противоестественного.
R>Второй — то, что разработчикам ПО надо будет учиться "делать больше, имея меньше". Допустим к подсветке синтаксиса хотим добавить автодополнение, значит либо надо выкинуть что-то старое, либо подсветку синтаксиса надо сделать в 2 раза быстрее, т.к. к следующему релизу компьютеры магически не станут в 2 раза быстрее.
Здравствуйте, Cyberax, Вы писали:
R>>Как тратить параллелизм на динамическую типизацию и интерпретацию языка не видится.
C>Посмотри на Erlang
Я думаю, что динамическая типизация/интерпретация в Erlang напрямую влияет на производительность отдельного процесса. Я не прав?
Афаик, параллелизм в Erlang используется только на более высоком уровне — на уровне отдельных процессов, но не на уровне выполнения отдельного процесса.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, remark, Вы писали:
R>>поскипано
G>Красиво написано, но.... Сильно вы преувеличиваете роль тактовой частоты процессоров в общем быстродействии компьютеров, вернее выполняемых программ. G>Почти всегда тормоза моего компа были связаны с недостатком памяти. G>Процессор нужен для чисто вычислительных задач, но они чаще всего отлично распараллеливаются.
Конечно. Разные бывают программы. Для некоторых вообще всех ресурсов хватает за глаза.
У меня лично на компьютере, редко когда для прикладных программ требуется больше доступных 1 или 2 Гб.
С другой стороны, что-то всегда будет боттлнеком программы. Допустим программа тормозит из-за недостатка памяти. Когда мы увеличим память, она будет уприраться во что-то другое. Правильно?
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, remark, Вы писали:
R>>Тут, кстати, намечаются интересные сдвиги. 40 лет мы получали Дивиденты Мура в виде увеличивающейся на 40-50% в год производительности процессоров. Дивиденты эти постоянно растрачивались вместе с получением новых. На что же они были растрачены? Значительная часть ушла на новые фичи и улучшение старых фич, а так же на увеличение обрабатываемых объемов данных. Сбавлять темпа растраты в этом направлении не понятно куда — пользователи не только привыкли к "крутым" фичам, но они так же и привыкли к тому, что новые фичи постоянно добавляются, а старые — улучшаются.
PD>Это само собой, но вот у реализации этих самых фич качество и оптимальность кода порой явно не на высоте. Я совершенно уверен, что многое из того, что сейчас сущетсвует, мы бы имели все равно, если бы лет 5 назад рост производительности компьютеров вообще прекратился бы. Не все, конечно, но многое. Просто писали бы эти фичи, исходя из того, что есть, а не в надежде на то, что будет. И пооптимальнее написали бы.
Ну 35 лет экспоненциального роста — это тоже не плохо
>>Другая значительная часть дивидентов ушла на практики "быстрой разработки", архитектуру ПО, бесчисленные уровни абстракции, новые "безопасные" языки и т.д. В этом направлении "откатываться" тоже особо не куда.
PD>Черт знает. Отката, скорее всего, не будет, верно, но вот оптимизация того, что есть — вполне возможна.
PD>А вообще все определяться будет развитием аппаратуры. Если узким звеном будет диск — ничего мы не получим, это нам почти не подвластно. Если же узким звеном будет процессор(ы) — то раньше или позже найдется кто-то, кто пошлет к чертовой матери все бесчисленные уровни абстракции и напишет продукт... нет, не на ассемблере, конечно, но такими средствами, котоорые позволят выжать из этого процессора(ов) все, что он(и) могут и не тратить это на всякую ерунду, а только по существу дела. Свято место пусто не бывает.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Если же узким звеном будет процессор(ы) — то раньше или позже найдется кто-то, кто пошлет к чертовой матери все бесчисленные уровни абстракции и напишет продукт... нет, не на ассемблере, конечно, но такими средствами, котоорые позволят выжать из этого процессора(ов) все, что он(и) могут и не тратить это на всякую ерунду, а только по существу дела. Свято место пусто не бывает.
А как же горизонтальное масштабирование? Тот же MapReduce, например, не просто так появился.
Здравствуйте, remark, Вы писали:
R>Конечно. Разные бывают программы. Для некоторых вообще всех ресурсов хватает за глаза. R>У меня лично на компьютере, редко когда для прикладных программ требуется больше доступных 1 или 2 Гб. R>С другой стороны, что-то всегда будет боттлнеком программы. Допустим программа тормозит из-за недостатка памяти. Когда мы увеличим память, она будет уприраться во что-то другое. Правильно?
Боттлнек есть всегда, но что-то не верится что им в ближайшем будущем станен именно быстродействие одного процессора.
Если посмотреть на такие библиотеки, как TPL (Task Parallel Library) от Microsoft, то разработка кода, применяющего параллелизм становится чрезвычайно простой. А динамическая типизация, сборка мусора и прочие вещи, вносимые современными языками и платформами даже сейчас создают пренебрежительно малые издержки.
Остается один вариант нарваться на такой боттлнек — исключительно вычислительная, абсолютно не распараллеливающаяся задача. К счастью таких очень мало.
Здравствуйте, remark, Вы писали:
R>Я думаю, что динамическая типизация/интерпретация в Erlang напрямую влияет на производительность отдельного процесса. Я не прав? R>Афаик, параллелизм в Erlang используется только на более высоком уровне — на уровне отдельных процессов, но не на уровне выполнения отдельного процесса.
Ну да, но Erlang при этом позволяет легко писать массивно-параллельные приложения.
Кроме того, есть ещё и OpenMP, умеющий распараллеливать обычный С.
Здравствуйте, WFrag, Вы писали:
WF>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Если же узким звеном будет процессор(ы) — то раньше или позже найдется кто-то, кто пошлет к чертовой матери все бесчисленные уровни абстракции и напишет продукт... нет, не на ассемблере, конечно, но такими средствами, котоорые позволят выжать из этого процессора(ов) все, что он(и) могут и не тратить это на всякую ерунду, а только по существу дела. Свято место пусто не бывает.
WF>А как же горизонтальное масштабирование? Тот же MapReduce, например, не просто так появился.
Если задача хорошо ложится на MapReduce, то мы в достаточно хорошем положении. Однако и тут надо учитывать, например, гранулярность. Сама MapReduce от Google рассчитана на очень крупно-гранулярные задачи — порядка десятков МБ данных на задачу. В некоторых областях встаёт необходимость в гранулярности в десятки байтов/сотни тактов на задачу.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, remark, Вы писали:
R>>Конечно. Разные бывают программы. Для некоторых вообще всех ресурсов хватает за глаза. R>>У меня лично на компьютере, редко когда для прикладных программ требуется больше доступных 1 или 2 Гб. R>>С другой стороны, что-то всегда будет боттлнеком программы. Допустим программа тормозит из-за недостатка памяти. Когда мы увеличим память, она будет уприраться во что-то другое. Правильно?
G>Боттлнек есть всегда, но что-то не верится что им в ближайшем будущем станен именно быстродействие одного процессора.
Мммм... всегда были и сейчас есть задачи, которые упираются в процессор. Например, компиляция.
G>Если посмотреть на такие библиотеки, как TPL (Task Parallel Library) от Microsoft, то разработка кода, применяющего параллелизм становится чрезвычайно простой.
Как мне с помощью неё распараллелить обработку связанного списка?
TPL хорошо обрабатывает только задачи организованные в сбалансированные деревья, так же как и любая другая реализация основанная на work-stealing.
Здравствуйте, Cyberax, Вы писали:
R>>Я думаю, что динамическая типизация/интерпретация в Erlang напрямую влияет на производительность отдельного процесса. Я не прав? R>>Афаик, параллелизм в Erlang используется только на более высоком уровне — на уровне отдельных процессов, но не на уровне выполнения отдельного процесса.
C>Ну да, но Erlang при этом позволяет легко писать массивно-параллельные приложения.
При этом. При этом — да.
Хотя легкость написания масштабируемых распределенных приложений немного вызывает сомнения на любом языке.
C>Кроме того, есть ещё и OpenMP, умеющий распараллеливать обычный С.
Хотелось бы поглядеть, например, на сетевой сервер, распараллеленый с помощью OpenMP. Или на 3D игру. Или на IDE. Или на базу данных. Или...
Здравствуйте, remark, Вы писали:
G>>Боттлнек есть всегда, но что-то не верится что им в ближайшем будущем станен именно быстродействие одного процессора. R>Мммм... всегда были и сейчас есть задачи, которые упираются в процессор. Например, компиляция.
Это как раз то, что отлично параллелится. Ликовка чуть похуже, но тоже возможно.
G>>Если посмотреть на такие библиотеки, как TPL (Task Parallel Library) от Microsoft, то разработка кода, применяющего параллелизм становится чрезвычайно простой. R>Как мне с помощью неё распараллелить обработку связанного списка? R>TPL хорошо обрабатывает только задачи организованные в сбалансированные деревья, так же как и любая другая реализация основанная на work-stealing.
В таком случае не надо параллелить обработку списка, вполне можно выбрать другие структуры данных, или разбить список на несколько или применить параллелизм к большей по объему задачи.
Естественно это потребует других приемов программирования, но серьезная оптимизация для одного процессора, как описано в первом посте, вряд ли понадобится.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, remark, Вы писали:
G>>>Боттлнек есть всегда, но что-то не верится что им в ближайшем будущем станен именно быстродействие одного процессора. R>>Мммм... всегда были и сейчас есть задачи, которые упираются в процессор. Например, компиляция.
G>Это как раз то, что отлично параллелится. Ликовка чуть похуже, но тоже возможно.
Я рад, что хоть у кого-то это не вызывает проблем...
G>>>Если посмотреть на такие библиотеки, как TPL (Task Parallel Library) от Microsoft, то разработка кода, применяющего параллелизм становится чрезвычайно простой. R>>Как мне с помощью неё распараллелить обработку связанного списка? R>>TPL хорошо обрабатывает только задачи организованные в сбалансированные деревья, так же как и любая другая реализация основанная на work-stealing.
G>В таком случае не надо параллелить обработку списка, вполне можно выбрать другие структуры данных,
Лучше всего распараллеливается обработка массивов. Но допустим нам надо так же вставлять и удалять из середины. Как быть?
G>или разбить список на несколько
Это уже лучше. Надо только не забыть про балансировку списков.
G>или применить параллелизм к большей по объему задачи.
Это ещё лучше. Но если обработка списка — это у нас единственная задача.
G>Естественно это потребует других приемов программирования, но серьезная оптимизация для одного процессора, как описано в первом посте, вряд ли понадобится.
Вообще, насколько я помню, про "серьезную" оптимизацию я ничего и не писал. И то, что ты приводишь, как раз и есть примеры "сборки Дивидентов Мура по-новому". Ну и кстати, вначале что бы определить, что у нас проблемы со списком, нам понадобится профайлер — тул для однопоточной оптимизации. А что бы сразу не бросаться перекраивать всё приложение на параллельное, логично было бы вначале попытаться "выжать" ещё немного из текущей однопоточной реализации.
Здравствуйте, remark, Вы писали:
G>>или применить параллелизм к большей по объему задачи.
R>Это ещё лучше. Но если обработка списка — это у нас единственная задача.
Списки не такой уж и маленький класс задач. Он, как и реляционка, позволяет неплохо представлять довольно широкий класс моделей. Не зря, собственно, Parallel FX тесно интегрирован с LInQ на прикладном уровне.
... << RSDN@Home 1.2.0 alpha 4 rev. 1095 on Windows Vista 6.0.6001.65536>>
