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

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

B084 (04.11.2010 11:40:14)

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

iZEN (04.11.2010 11:41:00)

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

tx (04.11.2010 11:41:14)

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

Legioner (04.11.2010 11:43:57)

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

Legioner (04.11.2010 11:45:23)

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

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

yoghurt (04.11.2010 11:54:24)

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

iZEN (04.11.2010 11:56:27)

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

А нужно ли?

RTP (04.11.2010 11:58:44)

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

RTP (04.11.2010 12:00:18)

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

Legioner (04.11.2010 12:01:46)

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

kranky (04.11.2010 12:03:28)

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

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

mv (04.11.2010 12:07:40)

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

Kosyak (04.11.2010 12:07:57)

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

Shtsh (04.11.2010 12:12:11)

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

mv (04.11.2010 12:15:35)

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

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

Relan (04.11.2010 12:19:28)

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

Shtsh (04.11.2010 12:19:47)

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

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

Relan (04.11.2010 12:21:56)

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

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

mv (04.11.2010 12:24:36)

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

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

DNA_Seq (04.11.2010 12:25:15)

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

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

iZEN (04.11.2010 12:27:57)

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

Legioner (04.11.2010 12:29:12)

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

tommy (04.11.2010 12:29:37)

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

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

devl547 (04.11.2010 12:33:14)

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

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

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

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

Relan (04.11.2010 12:36:42)

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

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

Legioner (04.11.2010 12:37:05)

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

DNA_Seq (04.11.2010 12:37:19)

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

pekmop1024 (04.11.2010 12:37:38)

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

devl547 (04.11.2010 12:38:53)

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

Chaser_Andrey (04.11.2010 12:41:05)

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

pekmop1024 (04.11.2010 12:41:07)

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

DNA_Seq (04.11.2010 12:41:54)

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

pekmop1024 (04.11.2010 12:43:08)

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

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

Led (04.11.2010 12:44:37)

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

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

isden (04.11.2010 12:44:49)

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

DNA_Seq (04.11.2010 12:44:54)

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

pekmop1024 (04.11.2010 12:46:11)

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

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

isden (04.11.2010 12:46:45)

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

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

drakmail (04.11.2010 12:47:15)

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

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

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

pekmop1024 (04.11.2010 12:49:28)

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

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

Legioner (04.11.2010 12:53:31)

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

Почему?

Relan (04.11.2010 12:54:53)

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

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

devl547 (04.11.2010 12:55:41)

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

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

isden (04.11.2010 12:57:14)

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

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

DNA_Seq (04.11.2010 12:58:44)

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

Dorif (04.11.2010 13:04:39)

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

Dorif (04.11.2010 13:05:56)

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

Dorif (04.11.2010 13:07:14)

>Почему?

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

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

devl547 (04.11.2010 13:08:55)