Многоядерные процессоры, как прогресс?

12 у amd, но для серверов 8 у интеля, для серверов.

AMD Phenom II X6 1045T всё ещё не продаётся. А я уже заранее планировал его покупку в ноябре-декабре.

Дык это, видеокарты.

Когда обычный код на C с pthreads заработают на видеокарте, тогда соглашусь, пока видеокарты для игрушек и декодинга видео.

Как я понимаю, там цены чуть менее чем заоблачные и для среднего компьютера за полторы тысячи долларов мало подходят.

>AMD Phenom II X6 1045T всё ещё не продаётся. А я уже заранее планировал его покупку в ноябре-декабре.

Зачем оно нужно на домашней (?) машине?

Для компиляции.

ну и в чем проблемы? Процессоры есть, даже для домашних ПК. Ну будут 50процессов ОСи размазываться по 6ти ядрам или 8потокам. Быстро? - Ьыстро.

А нужно ли?

Сам не пробовал, но таки мысль есть, что UI будет несколько быстрее окошками шевелить.

А в каком направлении прогрессировать? Я только за 1 процессор с терагерцовой частотой, но не хотят же делать, даже 10 гигагерц не перевалили.

Скоро Bulldozer от AMD должен в продажу поступить. Там 8 ядер для десктопа и 16 для сервера.

Были предсказания, что вроде закончилась гонка за мегагерцы и компактность. Но Мур никуда не делся, и продолжает плодить транзисторы, соотвественно логическим выводом будет увеличение количества процессоров/ядер.

Мур говорит только об увеличении производительности, а не о количестве транзисторов. В нехалеме и втором феноме, например, круто оптимизирована работа с памятью.

но не хотят же делать

Проблема не в том что нехотят, не могут.

как раз только о количестве транзисторов. Погугли. Или прямо пруфлинк кидать?

Да, ты прав. Хотя с основной массой транзисторов, идущих на кэш, корреляция между их кол-вом и производительностью как-то неочевидна.

> А в каком направлении прогрессировать? Я только за 1 процессор с терагерцовой частотой, но не хотят же делать, даже 10 гигагерц не перевалили.

Тепловыделение растет пропорционально квадрату частоты. А с ростом количества ядер происходит лишь линейный рост тепловыделения. Поэтому наращивание количества ядер выглядит перспективнее. Но всё упирается в оптимизацию софта.

Ну, про производительность никто не говорил :) Это не та величина, которую можно точно определить цифрами :)

> Скоро Bulldozer от AMD должен в продажу поступить. Там 8 ядер для десктопа и 16 для сервера.

На бумаге микроархитектура Бульдозера выглядит отлично, особенно аналог Hyper-Threading. Посмотрим, что будет на практике.

Ну, про производительность никто не говорил :) Это не та величина, которую можно точно определить цифрами :)

«Гордон Мур пришел к выводу, что при сохранении этой тенденции мощность вычислительных устройств за относительно короткий промежуток времени может вырасти экспоненциально.»

>Когда обычный код на C с pthreads заработают на видеокарте, тогда соглашусь

Обычный си-код не заработает никогда хотя бы из-за отсутствия прямого доступа к памяти. Вот какой-нибудь байткод наверное крутить можно будет

Сам не пробовал, но таки мысль есть, что UI будет несколько быстрее окошками шевелить.

А у вас оно при фоновой компиляции фризится? У меня даже на двухъядернике такого не наблюдается.

Я вообще считаю, что начиная с определённого числа ядер будет небольшая революция в мейнстримовых языках, такая же, какая произошла на переходе от С к Java/Python/..., когда быстрые процессоры позволили использовать более мощные абстракции, не слишком переживая по поводу оверхеда в производительности. Так и тут - начиная с определённого количества ядер техники автоматической параллелизации дадут профит больший, чем сопутствующие накладные расходы. Грубо говоря - Clojure, F#, мб изменённый Haskell пойдут в мейнстрим, т.к. писать код с локами и семафорами будет то же самое, что сейчас выделять память malloc-ом: можно, но большинство так не делает.

толку то от многоядерности когда софт так и не оптимизирован. вон mplayer через vdpau видео раскодирует аппаратно, но рассинхрон со звуком часто есть. и ничего не поделать. получается бред - mplayer гонит неперрежатое FullHD видео, использует всего несколько процентов но со звуком ерунда. кстати в под вендой народ жалуется на рассинхрон при звуке TrueHD.

>когда быстрые процессоры позволили использовать более мощные абстракции

ну то есть классика - есть быстрый проц, так мы набыдлокодим и он тормозить начнет.

> Так и тут - начиная с определённого количества ядер техники автоматической параллелизации дадут профит больший, чем сопутствующие накладные расходы. Грубо говоря - Clojure, F#, мб изменённый Haskell пойдут в мейнстрим

Тут есть два подхода. Первый, как вы сказали, — переход на чистые функциональные языки, которые естественным образом поддерживают распараллеливание. В ваш список я бы добавил еще Erlang.

Второй подход — создание средств, упрощающих распараллеливание на традиционных императивных языках. Например Grand Central Dispatch.

Скорее всего оба этих подхода будут сосуществовать.

Здесь важно то, что «быдлокодинг» даёт больше кода и больше функционала при меньшем количестве багов.

Идеальная программа написана на ассемблере, делает то что нужно, потребляет минимум памяти и процессора, не имеет багов и не существует.

Преждевременная оптимизация - корень всех зол (ц)

Давно так :)
Собственно, у этого есть и хорошая и плохая стороны.
Хорошая - позволяет прогрессировать процам.
Плохая - скатывает реальное качество ПО в унылое говно.

вот поэтому PC is an AMIGAAAAA!!!!

А как на меня - они просто медленно и последовательно высасывают деньги у потребителЯ, подкладывая порцию чуть больше и называя это технологической революцией, на что неосознанные покупатели ведутся.

Я считаю, что цена за прогресс железа небольшая. Срок жизни ПО в таких условиях невелик, и качественное мы увидим сразу, как кремниевые технологии упрутся в предел производительности. А это вполне обозримое будущее.

Качество ПО как раз за последние 20 лет выросло. Почитай например какой хитрый алгоритм использовали в 95й винде чтоб не перерисовывать часики каждую секунду

Я немного неправильно выразился.
Качество кода ПО. Хотя на качестве самого ПО это тоже сказывается.

>Максимум что видел - 6 ядер.

12 ядер * 4 процессора == 48 ядер. 512 Гбайт RAM. Врде как очень даже неплохо.

> Как то не видать 16-ядерных процессоров

они есть в продаже. тут даже проскакивало пару раз.
но не x86. x86 тоже есть - но пока в лабораториях. Интел, например, вовсю играется с 80-ти ядерными процами.
но тепловыделение там гигантское, нужно оптимизировать и техпроцесс уменьшать.
да, а еще дружно вспоминаем про видеокарты :)

См. про преждевременную оптимизацию. Если экономить каждый такт процессора то в итоге получиться Win95/98

Ну да, в будущей GTX580 - вообще 512 потоковых процессоров. Правда, что под пп понимают нвидиевцы, одним им известно.

> Я только за 1 процессор с терагерцовой частотой

это невозможно. http://otvety.google.ru/otvety/thread?tid=31fd279c5c1c761c
только разве что на оптике.

>Почитай например какой хитрый алгоритм использовали в 95й винде чтоб не перерисовывать часики каждую секунду

А ссылку можно? А то интенресно даже стало...

> См. про преждевременную оптимизацию. Если экономить каждый такт процессора то в итоге получиться Win95/98

Win9x - это набор костылей над системой (по сути) сорокалетней давности. Что ты от нее хочешь? Костыли никогда нормально не работают.

Я не говорю, что надо все на ассемблере писать - это крайность. Но и нынешние жабодотнеты - это 100% быдлокод by design, на этом просто нельзя иначе ничего сделать. Говно, на самом деле, но вполне соответствует технологическому этапу бурного роста: сейчас иначе просто невозможно.

Оптика, может ещё что.

Правда вопрос со скоростью памяти тоже важен. Я статистики не знаю, но мне кажется, что львиную долю времени даже сегодняшний процессор спит, ожидая ответа от запроса на чтение памяти на типичных задачах. Хотя интересно послушать тех, кто знает больше.

> Но и нынешние жабодотнеты - это 100% быдлокод by design

Почему?

> А это вполне обозримое будущее.

Скорее бы) Жду второе рождение демосцены.

> львиную долю времени даже сегодняшний процессор спит, ожидая ответа от запроса на чтение памяти на типичных задачах

а большие кэши на кристалле для чего по-твоему придумали? :)

Пока программисты не научатся писать код нормально - нужно. А не гоняться за профитом.

С тем же успехом можно заявить что любой исходник на си - быдлокод. А что? Компилятор си писался под узкую прикладную задачу а все что наворотили сверху - набор костылей. В винде гравику в ядро внесли не потому что не читали Кнута и Таненбаума а потому что экономили каждый такт процессора. Чем сложнее программа тем более вероятна что она глючит. KISS еще никто не отменял

Идеальная прога должна быть написана на машинных кодах, ибо даже ассемблеры не всегда выбирают самый оптимальный код.

Про выделение памяти malloc()- а как ещё выделять память под динамические переменные в C?

А можно поподробнее? Почему?

>Почему?

man a500/a1200
man плата акселератора
man оптимизация
man демосцена

//Просто потому что на амигах код на порядок лучше оптимизируют.