 |
 |
|
|
Место для Вашей рекламы!
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Предыдущие публикации:| 2006-07-20 | Четырехъядерные процессоры Intel появятся в 2006 году | |
| 2006-09-25 | Intel встает на все четыре | |
| 2006-10-22 | Intel демонстрирует 16-сильный сервер |
Обсуждение и комментарии |
 |
 | M&M's 9 Mar 2006 9:53 AM |
| ... а двухъядерные - на самом деле сдвоенные одноядерные. | |
| | |
| нц 9 Mar 2006 10:05 AM |
| ... а все вместе это просто туева хуча 8086 процессоров, а обилие статей про АМД в последнее время - просто совпадение | |
| | |
| Zzz... 9 Mar 2006 10:20 AM |
| И вообще, это всё - миллионы транзисторов, а никакие не процессоры... | |
| | |
| Прохожий 9 Mar 2006 10:43 AM |
| Если уж дальше продолжить мысль - то, никакие это не транзисторы, а атомы кремния | |
| | |
| Котофейкин 9 Mar 2006 11:27 AM |
| Хватит Флудить. Мне интересно что вообще твориться? И К чему это приведёт? И действительно ли сейчас АМД такстолько сильна? Или это просто раальная и очень щедрая ПиАр акция.? | |
| | |
| M&M's 9 Mar 2006 11:32 AM |
| Собсно, они экономят на гнездах для процессоров: > Размещение нескольких процессоров в одном корпусе для того, чтобы установить их в одно гнездо и тем самым повысить производительность серверов Копейка рубль бережёть :-) | |
| | |
| Котофейкин 9 Mar 2006 11:40 AM |
| Хм... Ну незнаю мне тогда будет проще купить нормальный полно функциональный сервер... Верне ну хотябы начального уровня на 2 Ксеона. И не будет проблем. разница в ценах то всёравно сведётся к минимуму.. Что за то что за это. Так что вот тут я и за думался... Не обнулится ли эта самая разница? | |
| | |
| Закоренелый Интеловец 9 Mar 2006 11:52 AM |
| Все последние публикации на данном ресурсе поразительно напоминаю строчки басни: Ай Моська(АМД?) - знать она сильна?! коль лает на слона (Интел?)? Отдельный респект M&M's :))) И вообще давно понятно, что АМД живет только благодаря Интел, не желающего наступать на грабли Микрософт :) | |
| | |
| neon 9 Mar 2006 12:42 PM |
| 2 Котофейкин Разница будет в цене лицензии на софт. В одном случае придётся платить как за один проц (с 4-мя ядрами), в другом как за два проца. | |
| | |
| Прохожий 9 Mar 2006 1:44 PM |
| Как мне сказали в ИБМ, процессоры от АМД плохо подходят для многопроцессорных серверов (больще 4) в силу своей архитектуры NUMA. То есть у АМДшных процов при большом количестве мелких операций с данными, требующих частого обновления кеша, наблюдается сильное замедление производительности. Для Интеловских процессоров ИБМ делает специальный чипсет, который обеспечивает все процессоры общим кешем. Поэтому количество Интеловских процов в серваке может быть большим. | |
| | |
| Михаил Елашкин - imho elashkin.com9 Mar 2006 1:59 PM |
| 2 Прохожий Я бы ответил, если бы было более грамотное объяснение позиции IBM. Я так понял, что речь идет о когерентности кэшэй или буквах сс в архитектуре ccNUMA. Что-то я сильно сомневаюсь в этом, сильно... просто у IBM есть чипсет для Intel и давно, а вот для AMD у них нет продукта - они прощелкали рост популярности AMD как и все крупные вендоры... | |
| | |
| Kostya - mkostyatx.technion.ac.il 9 Mar 2006 2:51 PM |
| кэшeй | |
| | |
| ПС 9 Mar 2006 3:20 PM |
| 2 М.Елашкин -=Что-то я сильно сомневаюсь в этом, сильно... просто у IBM есть чипсет для Intel и давно, а вот для AMD у них нет продукта=- Не только в том дело, что прощелкали. Просто у АМД процессор (в отличие от Интел) сам лезет памятью управлять, вместо чипсета. Поэтому разработать для него что-то ЭДАКОЕ гораздо сложнее вроде как бы... | |
| | |
| Прохожий 9 Mar 2006 3:21 PM |
| Для Михаила Елашкина Приблизительно правильно вы поняли. Речь идет именно о когерентности кешей. | |
| | |
| ПС 9 Mar 2006 3:37 PM |
| продолжение: Поэтому, у каждого процессора своя область памяти и свой отдельный кэш и все такое. Поэтому если надо залезть в память другого процессора, напрямую в нее "наш" процессор влезть вроде как не может - только через обращение к этому другому процессору. И при большом числе процессоров (8 или больше - что-то такое) это вроде вызывает заметное торможение. А с интеловскими процессорами вроде такого нет, поскольку они памятью не управляют, и вроде как ИБМ-овский под-интел-многопроцессорный чипсет просто показывает каждому процессору, что вся память его и больше ничья, а сам все обращения процессоров к памяти через общий кэш разруливает, и за счет этого "издержки на многопроцессорность" у ИБМ+Интел меньше. Вроде в общих чертах так, а подробности не помню - сорри. И насколько это все правда - не знаю. :) Ждем-с комментариев. :) | |
| | |
| ПС 9 Mar 2006 4:13 PM |
| В общем вроде какая-то там у АМД не совсем сс эта НУМА, чтоли... :) | |
| | |
| Михаил Елашкин - imhoelashkin.com 9 Mar 2006 4:49 PM |
| Ребята, вы чего там? х86 и ccNUMA не совместимы между собой в принципе. То, что делает IBM это ... нет, в принципе можно, но работает только для определенного круга задач, а для ряда других будет наоборот замедлять. Тут собственно и обсуждать нечего. Не не сделать на мотоциклетных моторчиках самосывал, даже если их много поставить. Это не хорошо и не плохо, просто не для этого архитектура эта. А тащить х86 на больше чем 4 процессора... ну 8, но все что выше уже ерунда полная. | |
| | |
| Прохожий 9 Mar 2006 5:49 PM |
| Для Михаила Елашкина А тащить х86 на больше чем 4 процессора... ну 8, но все что выше уже ерунда полная. --- Не могли бы вы обосновать? Вон у ИБМ и 16-процессорный сервачок на Интелах x86 есть. | |
| | |
| Прохожий 9 Mar 2006 5:51 PM |
| Для Михаила Елашкина То, что делает IBM это ... нет, в принципе можно, но работает только для определенного круга задач, а для ряда других будет наоборот замедлять. --- Например, какие задачи могут замедляться и почему собственно? Может ссылочку на какое исследование приведете? Очень интересно на самом деле. | |
| | |
| Чр 9 Mar 2006 6:15 PM |
| мощность процессора так же как и лампочки меряется в ваттах. АМД мощные процессоры в всех планах. | |
| | |
| Чр 9 Mar 2006 6:18 PM |
| сколько у вас ломпочек в люстре? почему до сих пор нет сдвоеных лампочек странно ведь? так бы перегорела одна нить горела бы другая.... | |
| | |
| Чр 9 Mar 2006 6:19 PM |
| один процессор это одна 7мая лошадиной силы. значит ли это что чтобы заменить лошади надо 7 проццсссров? | |
| | |
| ПС 9 Mar 2006 8:10 PM |
| 2 М.Елашкин -=То, что делает IBM это ... нет, в принципе можно, но работает только для определенного круга задач, а для ряда других будет наоборот замедлять. --- Например, какие задачи могут замедляться и почему собственно? Может ссылочку на какое исследование приведете? Очень интересно на самом деле.=- Правда, Михаил. Не сочтите за труд. :) Действительно интересно. :) | |
| | |
| iZEN - izenmail.ru 9 Mar 2006 10:01 PM |
| Давайте по числу процессоров сравнивать более-менее одинаковые конфигурации: http://icl.cs.utk.edu/hpcc/hpcc_results.cgi Condensed Results - Base Runs Only - 98 Systems - Generated on Sat Mar 4 12:35:39 2006: Cray XT3 AMD Opteron: 3744 процессора частотой 2.4GHz; моща 14.7040000 TFlop/s (10350 - вроде максимальное количество процессоров Opteron 2GHz только у Cray Inc XT3 AMD Opteron) SGI Columbia 2048 Intel Itanium 2: 2024 процессора частотой 1.6GHz; моща 9.3196500 TFlop/s (для Intel Itanium 2 это - максимально возможное число процессоров?) IBM p655 Power4+: 2048 процессоров частотой 1.5GHz; моща 6.2094300 TFlop/s (число процессоров PowerPC может быть и больше - смотрим IBM BlueGene/L PowerPC 440 с 65536 процессорами частотой 0.7GHz и рекордной производительностью в 80.6830000 TFlop/s. Браво, RISC!!!) | |
| | |
| bravomail.livejournal.com 9 Mar 2006 10:21 PM |
| тоже мне - узнали тайну, что дважды два = четыре. вот если бы пять или три... | |
| | |
| ПС 9 Mar 2006 11:51 PM |
| 2 iZEN -=Cray XT3 AMD Opteron: 3744 процессора частотой 2.4GHz; моща 14.7040000 TFlop/s (10350 - вроде максимальное количество процессоров Opteron 2GHz только у Cray Inc XT3 AMD Opteron)=- Это все чуточку не то. Это суперкомпьютеры с MPP-архитектурой - короче говоря 3744 (или 10350, наверное можно и больше - не знаю) самостоятельных компьютерчика, рассчитывающие что-то параллельно. Мы говорили о другой архитектуре. :) | |
| | |
| Maкс 10 Mar 2006 1:16 AM |
| Прохожий: особенности ccNUMA в быстром доступе к локальной (некогерентной) памяти, и относительно медленном доступе к глобальной памяти. Кол-во процессоров напрямую тут не причём, скорее уж, проблемы масштабирования проявляются у SMP заметно раньше. Сложно увеличить производительность симметричных шинных архитекур при увеличении участников выше 16. | |
| | |
| Михаил Елашкин - imhoelashkin.com 10 Mar 2006 9:50 AM |
| (ЧАсть 1) Почему может замедляться решение задачи на ccNUMA машинах? Есть ряд причин, скажем рекомендую почитать диссертацию Димы Романова (раньше работал в Sun), там он показывает, что при некотором количестве задач система может войти в состояние, когда она непрерывно занимается переключением задач, а не счетом. Т.е. синхронизация кэшэй занимает больше времени, чем счет. Вот только ссылку дать не могу. Диссер надо брать на бумаге, а в виде статей ничего нет. Попробую своими словами. Есть такая проблема - процесс А работает на процессоре 1, потом отдает его по "тикам" и ждет свободного процессора, чтобы продолжить работу. Допустим освободился процессор 7. Он явно находится на другом qbb - 4-х процессорном модуле в архитектуре NUMA. ОК. Давай туда отдадим процесс А. Но на процессоре 1 могут остаться кусочки его данных в кэше. Их надо синхронизовать. Даем команду и "сс" срабатывает - передает данные от процессора 1 к процессору 7. Итд... Но вот при некоторых условиях может получиться так, что таких передач станет очень много. Кэши начинают "фрагментироваться" и производительность падает. Т.е. либо ОС либо аппаратура должна принимать решение - отправлять процесс А на процессор 7 или подождать когда освободится процессор 1, чтобы не гонять по системе содержимое кэша процессора 1. На первом этапе решение было записано в ОС - там формула оценки была - когда передавать на другой процессор, а когда ждать. Кстати, именно этот код и был добавлен IBM в Linux и за это на них наехали эти, как их там... забыл ) Потом решение передали на усмотрение железа. Сосбвенно коммутатора, хаба или бэкплэйна - как угодно. Это одна из причин почему только несколько компаний в мире умеет делать ccNUMA сегодня. Вот тот же Dell не умеет. Там даже несколько уровней принятия решения есть у того же Sun, а что вы хотели - 108 процессоров арбитрировать ))) | |
| | |
| Михаил Елашкин - imhoelashkin.com 10 Mar 2006 9:57 AM |
| (Часть 2) Теперь посмотрим на софт. Софт должен знать, что его могут перекидывать с процессора на процессор и чего это может стоить ему. Скажем MS SQL 2000 не имел понятия о таком поводении по своему дизайну и там было очень непросто его заставить на Итаниумах работать правильно. В целом, в наших тестах, оказалось выгоднее зажать 4 процессора из 16 на системные задачи и оставить 12 остальных на SQL. А то они там уж очень фестивалили - прыгали с процессора на процессор ))) Но мы не доделали тесты - может нам пришлось бы по другому сделать. Т.е. софт должне быть написан так, что он знает, что он может прыгать в несимметричной ахитектуре. Точнее софт должен быть многопотоковым и управляемым. А управлять этим должна ОС - она говорит железу как себя вести. Вот тут лежат колосальные запасы по настройке. Но для этого нужно понимать как работает софт и как он ложится на железо. Таких специалистов в мире не очень много. В основном или те или другие... Да, SQL 2005 умеет настраиваться на ccNUMA и знает об этом. Но вот в чем беда - а если процессоры двухядерные? Т.е. они не просто на одном qbb, а на одном кристалле и имеют скажем общий кэш? Для софта эта важно - переход задачи на такой процессор-сосед отличается от пехода на другой чип даже в пределах qbb. А если многопотоковые? Т.е. логический процессор? Как вести себя софту? Беда в том, что сейчас ни один софт не умеет работать эффективно с новыми типами процессоров ((( | |
| | |
| Михаил Елашкин - imhoelashkin.com 10 Mar 2006 10:00 AM |
| А что до замедления на IBM xSeries 440 и далее. То там, скорее всего реализован скорее кластер в корбке. Т.е. два и более 4-х процессорных qbb связаны скорее как кластер, а не как SMP. А там производительность сильно зависит от возможности распаралелить задачу. Ну уверен, но похоже. Да, посмотрите, кстати, неплохую статейку http://citforum.ru/hardware/arch/smp8opteron/ некоторые базовые вопросы там есть | |
| | |
| Прохожий 10 Mar 2006 10:57 AM |
| Для Михалиа Елашкина Премного благодарен. | |
| | |
| Михаил Елашкин - imhoelashkin.com 10 Mar 2006 7:26 PM |
| Да, вопрос этот не простой. Я вот был на MS Platforma и участвовал (сидел в президиуме) в сессии по производительности для разработчиков. Я ушел через 15 минут. Народ обсуждал реализации того или иного оператора, при этом в зале ни один человек ни на секунду не задумывался, что эта штука будет работать на сервере, где будет больше одного процессора итд итп 99.9999% разработчиков считает, что это hardware problem. Может и аппаратная, но ... аппаратуре надо хоть знать чего софт хочет - она тогда оптимизируется. Ну и софт должен уметь давать возможность настройщику управлять потоками... | |
| | |
| Прохожий 10 Mar 2006 8:11 PM |
| Прочитал статью. Слабовата, на мой взгляд. Мне встречалось исследование ИБМ по поводу производительности Оптеронов. Ну так оно подтверждает то, что они сказали мне устно по поводу когерентности кешей процессоров. | |
| | |
| ПС 10 Mar 2006 10:12 PM |
| В статье про родные интеловские чипсеты говорится... А вот про другие варьянты - неа. Вопрос, что ж там ИБМ такое выдумало для Интелов остается. И насколько оно таки эффективно. Или же сказочно и придумано... :) А насчет оптимизации софта - ну может в чем-то они и правы, эти человеки? Какие-то конечно "стандарты" программирования под многопроцессорные системы должны быть. Но не переделывать же весь свой софт каждый раз, как интел или амд или еще там кто выдумает очередной гипер-тридинг. | |
| | |
| M&M's 11 Mar 2006 10:52 AM |
| 2 Михаил Елашкин: > Беда в том, что сейчас ни один софт не умеет работать эффективно с новыми типами процессоров Вот оно :-) Я как раз хотел задать вопрос - для каких задач могут использоваться такие сложные архитектуры, и какой софт для них используется. Ну, уже ясно :-) | |
| | |
| SlvUn - slvunmail.ru 11 Mar 2006 5:50 PM |
| 2Михаил Елашкин: Респект. Михаил, вопросик есть в данной тематике, может Вы просветите? Несколько раз слышал про SUN, что их основная особенность и фича так сказать, в том, что когда пишешь проект какой-нибудь, не надо думать о масштабируемости. То бишь написал программулину, увеличилась нагрузка - докупил плату с процессорами, вставил ее в сервер, а система (Solaris ес-но) уже самостоятельно раскидывает и распаралеливает задачу. То есть SUN выбирают, когда пишут самостоятельно какие-то тяжеловесные приложения, с возможным резким увеличением нагрузки. И что у SUN лучший КПД по масштабируемости. Не могли бы сказать пару слов по этому поводу? | |
| | |
| Desperado 11 Mar 2006 7:04 PM |
| 2SlvUn ага, а еще спарки заряжают воду, лечат бесплодие и по христианским праздникам чудеса показывают. | |
| | |
| SlvUn - slvunmail.ru 11 Mar 2006 7:16 PM |
| 2Desperado: В Вашем посте замена слова спарки на Itanium или RISC к потере смысла не приводит, следовательно данное сообщение несет ноль полезной информации :) Я не компетентен в области многопроцессорных систем и их отличии друг от друга, но то утверждение о SUN слышал из уст людей далеко не глупых, потому и попросил прояснить этот момент у знающего человека, ежели у того будет на это желание. Не могу же люди от балды покупать технику за ТАКИЕ деньги, если она ничем не отличается от x86. | |
| | |
| Desperado 11 Mar 2006 8:35 PM |
| 2SlvUn В спарках нет ничего чудотворного, они не изцеляют калек, у них не вырастают слоты для процессоров. Если никто не подумает о масштабируемости то и SUN не сделает чудо. Если апликация работает в одном процессе то никто ее не сможет распараллелить. А платят потому, что это кому-то нужно. у кого-то софт который они при всем желании не могут перенести куда либо, другие искрене считают, что для его задачи спарки лучше, третьих обработали маркетологи ... | |
| | |
| Прохожий 12 Mar 2006 12:23 AM |
| Для Desperado Ну у Спарков внутри 4 потока, вроде, одновременное могут исполняться. Так сказать продвинутая многопоточность. Плюс кеш у процессоров неплохой. А вот частота тактовая подкачала. Думаю (хотя на все 100 не уверен), что в однопоточной задаче тот же Интел Ксеон двуядерный переплюнет Спарк по производительности (а возможно, что не только в однопоточной, но тут у меня сомнений больше). Может кто опровергнет сиё? | |
| | |
| SlvUn - slvunmail.ru 12 Mar 2006 12:21 PM |
| 2Desperado: Да собственно говоря я не столько про спарки спрашивал, сколько по Solaris. Граматное размещение программы по процессорам - это все таки дело ОС. В общем ждем Михаила :) | |
| | |
| Desperado 12 Mar 2006 2:01 PM |
| 2Прохожий на счет ксеона не знаю но вот 2-way opteron показывает примерно тот же результ что и T200 http://www.sap.com/solutions/benchmark/pdf/cert4705.pdf http://www.sap.com/solutions/benchmark/pdf/cert2405.pdf единственно совсем не понятно почему у сана тот же оптерон показывает в 2 раза худший рузультат http://www.sap.com/solutions/benchmark/pdf/cert0306.pdf | |
| | |
| Прохожий 12 Mar 2006 10:12 PM |
| для SlvUn Граматное размещение программы по процессорам - это все таки дело ОС. --- По-моему, не совсем так. Дело ОС - выделять какие-то ресурсы приложению по его запросу. А вот оптимальным образом использовать эти ресурсы - это уже дело самого приложения. Но это я так думаю. На самом деле как происходит я не знаю. | |
| | |
| Прохожий 12 Mar 2006 10:19 PM |
| Для Desperado В этих тестах у Сана время отклика в два раза меньше и памяти на сервере в два раза меньше. Может быть поэтому. | |
| | |
| Михаил Елашкин - imhoelashkin.com 13 Mar 2006 9:39 AM |
| 2 SlvUn Чудес не бывает, но с моей точки зрения и по оценкам некоторых специалистов Sun имеет наиболее отработанную систему многопроцессорности. К тому же они считают бинарную совместимость одной из важнейших фишек. Т.е. софт написанный для очень старых систем продолжает работать и на новейших. Это оченно полезно - т.е. системы зрелые и обкатанные. Но я бы о другом сказал. О Ниагаре или Т1 процессорах. Тут народ в потоке не совсем верно понимает. Т1 это хитрая штука. Т.е. это специализированный процессор. Ну есть DSP и прочие спецпроцессоры, а это хитрее. Он специализируется не на выполнение определенных команд или операций, а на типе нагрузки. Т.е. из процессора выкинуты все предсказания ветвления. Фактически он находится на уровене СПАРК-2 по развитию. Но! 4 потока (СМТ) на ядро с быстрым переключением. И 8 ядер со своим хабом на кристалле! В результате очень низкое энергопотребление, феноменально низкое. Как работает? А как только промах на ядре, т.е. данных нет в кэше, то тут же переключается на другой поток на томже ядре. И делает это очень быстро не страдая интеллектом. Когда это работает? Да в одном случае, когда всегда есть много потоков, которые ждут процессора. Очень много. А это сервер приложений Java (EJB, J2EE). В этом случае Т1 просто страшная молотилка - очень дешевая и эффективная, но только для таких задач. Если поставить на эту машину счетную задачу на Си написанную в один поток, то... это будет просто жопа. Т.е. это специализированный процессор для серверов приложений. А что для СУБД - СУБД не создает много потоков? А для этой задачи разрабатывается другой процессор - Rock. Настроенный именно на такой тип нагрузки. Причем бинарная совместимость по прежнему гарантируется для всех процессоров. Я считаю, что это гениально - специализированный процессор по типу нагрузки. | |
| | |
| Михаил Елашкин - imhoelashkin.com 13 Mar 2006 9:41 AM |
| 2 Прохожий и SlvUn Как минимум нужно иметь возможность настраивать систему - т.е. прямо сказать какую политику проводить по поводу переключения задач. Но идея Sun со специализированными для задач процессорами мне нравится ) | |
| | |
| Прохожий 13 Mar 2006 10:42 AM |
| Для Михаила Елашкина Но идея Sun со специализированными для задач процессорами мне нравится ) --- А мне не очень. Сейчас поясню почему. 1. Серверы Сан не отличаются дешевизной. 2. Если предприятие сравнительно небольшое, и оно покупает технику Сан под определенные задачи, то взаимозаменяемость таких серверов в будущем - не очень. Я имею ввиду, что сейчас сервер под AppServer используется, а завтра (ну года через три) под что-нить другое. А под что-нить другое его уже не очень хорошо ставить, поскольку не оптимизирован он под это. | |
| | |
| Прохожий 13 Mar 2006 11:06 AM |
| 3. Кроме того, набирают обороты всякие виртуализаторы. А это значит, что на сервере могут крутиться разные по нагрузке задачи. На Сановский специализированый сервер такие задачи лучше не ставить, поскольку опять же не оптимизирован он под это. | |
| | |
| Desperado 13 Mar 2006 11:16 AM |
| >Я считаю, что это гениально - специализированный процессор по типу нагрузки. этой гениальной идее в обед 100 лет, одних жаваускорителей сколько понаделали ... | |
| | |
| ПС 13 Mar 2006 2:46 PM |
| -=Если предприятие сравнительно небольшое, и оно покупает технику Сан под определенные задачи, то взаимозаменяемость таких серверов в будущем - не очень.=- Но никто и не заставляет "небольшое предприятие" САН-ы покупать. А смысл покупать микроскоп, чтоб потом предъявлять претензии, что им нецудобно гвозди забивать? :) | |
| | |
| Прохожий 13 Mar 2006 3:50 PM |
| Для ПС Но никто и не заставляет "небольшое предприятие" САН-ы покупать. А смысл покупать микроскоп, чтоб потом предъявлять претензии, что им нецудобно гвозди забивать? :) --- К словам придираться вздумали? От того, что слово "небольшое" заметить на "большое", что-то изменится? Или в больших предприятиях денег не считают? | |
| | |
| Прохожий 13 Mar 2006 3:50 PM |
| заметить - заменить | |
| | |
| Михаил Елашкин - imhoelashkin.com 13 Mar 2006 5:02 PM |
| Кстати, надо посмотреть как виртуальные машины будут под Т1 работать. Но насколько я понимаю это просто будут контейнеры Соляриса? Есть тут спецы по десятой Солярке? | |
| | |
| Михаил Елашкин - imhoelashkin.com 13 Mar 2006 5:03 PM |
| 2 Desperado джаваускоритель это спецпроцессор под язык. а тут бинарная совместимость по языку и специализация под нагрузку ) | |
| | |
| Pers 13 Mar 2006 8:07 PM |
| 2Прохожий, не совсем понятно неудовольствие. Вроде как производитель честно говорит что ниагара только для задач с большим количеством потоков, причем задачи с целочисленной математикой (там по помему один блок для вычислений с плавующей точкой). если планируешь менять задачи для железа, то и бери его с расчетом на это, с запасом. другой вопрос, зачем людям которым нужно гонять много простых потоков, брать/платить за избыточную (для них) функциональность? а вот по стоимости санов - это да, согласен. комплектуха черезчур дороговата. хотя последнее время все больше и больше ПО мигрирует на x86 и линукс. и сану эту тенденцию будет сложно сломать, я думаю. | |
| | |
| Desperado 13 Mar 2006 9:46 PM |
| 2Elashkin непонял, а чем бимерский System z9 Integrated Information Processor (zIIP) не "специализация под нагрузку" ? чем процессоры для игровых консолей не "специализация под нагрузку" !? | |
| | |
| Михаил Елашкин - imhoelashkin.com 13 Mar 2006 10:02 PM |
| 2 Desperado мотивируй | |
| | |
| Desperado 13 Mar 2006 10:13 PM |
| в консолях типа sony playstation, nintendo и прочих всю жизнь были специализированые процессоры специализация которых была графика. они всю жизнь старались оставить бинарную совместимость и местами им это вполне удавалось. zIIP специализированый процессор который втыкается рядом с процами общего назначения в мейнфрем, сейчас его умеет нагружать db2, в дальнейшем научат и другие приложения ... | |
| | |
| ПС 13 Mar 2006 11:34 PM |
| 2 М.Елашкин -=Кстати, надо посмотреть как виртуальные машины будут под Т1 работать. Но насколько я понимаю это просто будут контейнеры Соляриса?=- Вроде да. Ни о чем другом Сан вроде ничего такого не говорил. :) 2 Прохожий Ув.Pers уже ответил весьма адекватно. Добавлю, что непонятно, что это за предприятие такое (большое или нет), которое сначала покупает такое специализированное, ДОРОГУЩЕЕ железо, а потом вдруг у него так тех-процессы меняются, что его надо срочно под СУБД (например) кидать. :) | |
| | |
| Михаил Елашкин - imhoelashkin.com 14 Mar 2006 8:21 AM |
| 2 Desperado Не, ты не въехал в идею. Смотри, есть специализированные процессоры, скажем из графических карт. Они имеют специальный набор команд. Для примера отличие тех же х86 в том, что они выполняют набор общих команд. Конечно можно считать и графику, но также можно считать и звук и изображение и термодинамику... т.е. это универсальные процессоры. А вот графический процессор не может считать термодинамику или делать текстовый процессор. Фишка Т1 в том, что он является универсальным по сути процессором. Т.е. можно считать любые задачи, а не ограниченный набор. Его специализация именно в том, что он расчитан на работу в многозадачной и многопотоковой среде. Он будет работать и в однозадачной и однопотоковой среде как и любой универсальный процессор. Тот же SPARC или Pentium. Его "специализированность" в том, что он дает максимальную производительность именно в случае многопотоковости. Т.е. специализация не по командам, а по типу нагрузки. | |
| | |
| Desperado 14 Mar 2006 9:54 AM |
| 2Михаил Елашкин да, не понимаю, бери специализированый sony playstation 1 объединяй в кластер и расчитывай что хочешь. хочешь звук, хочешь термодинамику, в чем проблема ? Его специализация именно в том, что он расчитан на работу в однозадачной и однопотоковой среде. Он будет работать и в многозадачной и однопотоковой среде как и любой универсальный процессор. Тот же SPARC или Pentium. Его "специализированность" в том, что он дает максимальную производительность именно в случае расчета графики. Т.е. специализация не по командам, а по типу нагрузки. | |
| | |
| Прохожий 14 Mar 2006 11:13 AM |
| Для Pers, ПС не совсем понятно неудовольствие. Вроде как производитель честно говорит что ниагара только для задач с большим количеством потоков, причем задачи с целочисленной математикой (там по помему один блок для вычислений с плавующей точкой). --- Я разве где-то говорил, что производитель врёт? Я говорил, что взаимозаменяемость таких серверов плохая для задач с разными типами нагрузок. В этом и неудовольствие. Добавлю, что непонятно, что это за предприятие такое (большое или нет), которое сначала покупает такое специализированное, ДОРОГУЩЕЕ железо, а потом вдруг у него так тех-процессы меняются, что его надо срочно под СУБД (например) кидать. --- А вы еще раз ВНИМАТЕЛЬНО перечитайте мой пост (причем все пункты от 1 до 3 включительно). Где я говорил, что "вдруг срочно"? Я говорил, что через некоторое время, когда сервер под текущей задачей перестанет удовлетворять потребности (обычно года через три такое происходит). Про виртуализацию есть что возразить? | |
| | |
| ПС 14 Mar 2006 12:44 PM |
| 2 Прохожий -=Я говорил, что взаимозаменяемость таких серверов плохая для задач с разными типами нагрузок. В этом и неудовольствие.=- Ну то есть тот факт, что микроскопом гвозди не позабиваешь, Вас тоже сильно беспокоит? :) -=Я говорил, что через некоторое время, когда сервер под текущей задачей перестанет удовлетворять потребности (обычно года через три такое происходит).=- 1. Такое обычно происходит только на стремительно растущих или стремительно умирающих предприятиях. Но тогда зачем такому предприятию покупать Сан, если могут возникнуть ТАКИЕ проблемы? Крутизну показать? Тем более, что Сан ведь предупреждал... :) -=Про виртуализацию есть что возразить?=- А что тут возражать? Если какой-то "Вася" купит себе не то железо и начнет на нем что-то "виртуализировать", то у него получится не очень хороший результат. НО САН ВЕДЬ ПРЕДУПРЕЖДАЛ!!! По моему кому-то просто хочется поспорить. ;) | |
| | |
| Прохожий 14 Mar 2006 3:21 PM |
| Для ПС Ну то есть тот факт, что микроскопом гвозди не позабиваешь, Вас тоже сильно беспокоит? :) --- Непонятно на основании чего вы сделали такой вывод, будто я предлагал микроскопом гвозди забивать? Будьте добры, процитируйте меня, если я не прав. 1. Такое обычно происходит только на стремительно растущих или стремительно умирающих предприятиях. Но тогда зачем такому предприятию покупать Сан, если могут возникнуть ТАКИЕ проблемы? Крутизну показать? Тем более, что Сан ведь предупреждал... :) --- Сан как раз и незачем покупать таким предприятиям, а, возможно, и другим тоже (у которых много других серверов, но которые деньги умеют считать тем не менее, чтобы избежать в будущем возможных проблем, могущих возникнуть вследствие плохой взаимозаменяемости серверов). Именно поэтому он и неудобен. Об этом я и говорил. А что тут возражать? Если какой-то "Вася" купит себе не то железо и начнет на нем что-то "виртуализировать", то у него получится не очень хороший результат. НО САН ВЕДЬ ПРЕДУПРЕЖДАЛ!!! --- Именно этим серверы Сан и неудобны, что виртуализировать на них разные по степени нагрузки задачи неудобно. Кстати, а где вы видели фразу, что Сан предупреждает кого-то о чем-то при покупке их серверов? ;-) По моему кому-то просто хочется поспорить. ;) --- По-моему, вам достаточно взглянуть в зеркало, чтобы узнать кто именно. ;-) | |
| | |
| xxx 14 Mar 2006 4:30 PM |
| 2Прохожий: Если не знаете под какой тип нагрузки будет использоваться сервер - что мещает взять сервер на UltraSparc IV ? Их как бы никто не собирается пока снимать с производства... Там и Oracle показывает хорошую производительность и application servers. А если взять что-нибудь типа SF15K/25K, то там можно по мере необходимости перекидывать systemboards из домена в домен... Что касается Ниагары - тут наши клиенты уговорили местный офис SUN дать погонять сервер из демо фонда. Собственно они были первыми в очереди на тестирование этого сервера. После того, как погоняли - хотят закупать несколько штук. Уж очень хорошую производительность он показал под их задачей (application server в ERP). | |
| | |
| ПС 14 Mar 2006 5:51 PM |
| 2 Прохожий -=Непонятно на основании чего вы сделали такой вывод, будто я предлагал микроскопом гвозди забивать? Будьте добры, процитируйте меня, если я не прав.=- -=чтобы избежать в будущем возможных проблем, могущих возникнуть вследствие плохой взаимозаменяемости серверов=- Вас ведь Ниагара не устраивает? Или я что-то не так понял? Т.е. специализированный процессор Вам не нравится своей неуниверсальностью. Это и есть микроскоп и гвозди. Не покупайте то, что Вам не нужно. Но предъявлять миру (или Сану) претензию, что он существует - несколько глупо. -=Кстати, а где вы видели фразу, что Сан предупреждает кого-то о чем-то при покупке их серверов? ;-)=- Слышал лично от представителей Сан. Судя по тому, что и другие слышали, Сан таки предупреждает. ;) -=Именно этим серверы Сан и неудобны, что виртуализировать на них разные по степени нагрузки задачи неудобно.=- Не "серверы Сан", а "серверы Сан с процессорами Ниагара". Ну дык и не "виртуализируйте". Чего долдонить одно и то же. :) -=По моему кому-то просто хочется поспорить. ;) По-моему, вам достаточно взглянуть в зеркало, чтобы узнать кто именно. ;-)=- Глянул. Узнал. Хочется Вам. Успехов. | |
| | |
| Прохожий 14 Mar 2006 6:06 PM |
| для xxx Если не знаете под какой тип нагрузки будет использоваться сервер - что мещает взять сервер на UltraSparc IV ? Их как бы никто не собирается пока снимать с производства... Там и Oracle показывает хорошую производительность и application servers. --- Насколько хорошую? Мне вот думается, что Интел Ксеон 3.0 двухядерный побъет по производительности последний Спарк. Можете сие опровергнуть? | |
| | |
| Прохожий 14 Mar 2006 6:18 PM |
| Для ПС Вас ведь Ниагара не устраивает? Или я что-то не так понял? Т.е. специализированный процессор Вам не нравится своей неуниверсальностью. Это и есть микроскоп и гвозди. Не покупайте то, что Вам не нужно. Но предъявлять миру (или Сану) претензию, что он существует - несколько глупо. --- Я и не предъявлял Сану претензию, что он существует. Это вы откуда взяли? Да и не собирался покупать я Ниагару ни под каким соусом. Просто выразил недоумение по поводу восторга Елашкина о гениальности этой самой Ниагары. Ничего гениального нет, кроме пониженного энергопотребления. А то, что она специализирована под ОПРЕДЕЛЕННУЮ нагрузку я не считаю плюсом, скорее минусом. Вот и всё. Или вы считаете, что универсальный процессор это тоже самое, что микроскоп для гвоздей? Если так, то странно, как это Интел до сих пор существует, а равно и все другие производители универсальных процессоров (да тот же Сан, к примеру с его Спарками). Не "серверы Сан", а "серверы Сан с процессорами Ниагара". Ну дык и не "виртуализируйте". Чего долдонить одно и то же. :) --- Ну так и не буду. А долдоните вы в данном случае. Не пойму зачем. :-P Глянул. Узнал. Хочется Вам. Успехов. --- Странно, что вы глядя на себя в зеркало видите там мое отражение. | |
| | |
| Pers 14 Mar 2006 6:21 PM |
| 2Прохожий, поясни, пожалуйста, зачем покупать "специализированную" машину, если план развития предприятия предпологает смену _специализации_ машины? понятно, что в этом случае, при нерасчетных нагрузках - результат будет вызывать ожидаемое неудовлетворение. Но если план развития предпологает использования ПО которое хорошо параллелится, имеет механизмы кластеризации, то зачем брать машины общего назначения? В случае понимания куда идет организация - можно сьэкономить немалые средства и на железе и на энергии и охлаждении. А из универсальных вариантов - берите оптероны. на сегодня - лучшее решение в данном случае. мое мнение. P.S. сейчас хохму расказали - одни юмористы пытались java-вариант quake запустить на холодильнике, у которого процессор есть для java программ и жк-мониторчик Ж-) | |
| | |
| Pers 14 Mar 2006 6:27 PM |
| по поводу идеи. идея интересна - если посмотреть на современные ВЦ - то у них одно свойство проявляется все сильнее и сильнее - усиливающаяся специализация - жуткие числодробилки или телекомуникационные джунгли стоек серверов. при такой тенденции - специализация серверов, с сохранением возможности запускать общие программы, - плюс. идея то сторакак мир, просто сейчас она вышла из корпуса компьютера (специализация блоков и узлов компьютера) на уровень месейств серверов. вот и все. | |
| | |
| Прохожий 14 Mar 2006 7:12 PM |
| Для Pers поясни, пожалуйста, зачем покупать "специализированную" машину, если план развития предприятия предпологает смену _специализации_ машины? --- Ты всегда так тщательно сможешь спланировать что у тебя под какой нагрузкой будет работать через несколько лет? Но если план развития предпологает использования ПО которое хорошо параллелится, имеет механизмы кластеризации, то зачем брать машины общего назначения? --- Если специализированные машины СУЩЕСТВЕННО лучше машин общего назначения, тогда нет смысла брать машины общего назначения. Но так ли это на самом деле? А из универсальных вариантов - берите оптероны. на сегодня - лучшее решение в данном случае. мое мнение. --- У ИБМ несколько другое мнение :-). Мнение ИБМ приводится чуть раньше. Я хотел здесь выяснить может ли кто опровергнуть мнение ИБМ. Никто пока толком не смог, как мне кажется. идея интересна - если посмотреть на современные ВЦ - то у них одно свойство проявляется все сильнее и сильнее - усиливающаяся специализация - жуткие числодробилки или телекомуникационные джунгли стоек серверов. --- Как на счет виртуализации, всё-таки? Тенденции в ее сторону тоже есть. А вообще по поводу специализации не до конца понятно как долго она еще продлится. Вкладывать деньги в туманную перспективу не очень хочецца. | |
| | |
| Михаил Елашкин - imhoelashkin.com 14 Mar 2006 9:36 PM |
| 2 Desperado не, у PS2 три процессора: счетный, видео и спецэффектов, если я правильно помню их специализацию. только счетный более-менее универсальный и может с напрягом посчитать операции для графики. Остальные могут делать только то, для чего предназначены. | |
| | |
| Desperado 14 Mar 2006 11:34 PM |
| 2Михаил Елашкин ерунда. A US research centre has clustered 70 Sony PlayStation 2 game consoles into a Linux supercomputer that ranks among the 500 most powerful in the world. ... NCSA said in the report their system could theoretically deliver half a trillion operations per second, which equals 0.5 teraflops of computing power. If it performs as promised, the machine will rank amongst the world's top 500 supercomputers. http://news.zdnet.co.uk/software/developer/0,39020387,21353 01,00.htm | |
| | |
| xxx 15 Mar 2006 6:29 AM |
| 2:Прохожий > Насколько хорошую? Что, цифры привести ? Так смртрите соответствующие тесты. Или спросите у Михаила - аналитика это его область. Я могу только сказать, что на тех объёмах, которые есть у наших клиентов, Intel просто близко не валялся: SF6800 в полной набивке (6 SB: 24 CPU USIIICu 1.2GHz/192Gb RAM + 12 2Gb/s FC HBA ) + 16TB Oracle tablespace. > Мне вот думается, что Интел Ксеон 3.0 > двухядерный побъет по > производительности последний Спарк. А причём тут процессор ? Мы рассматриваем "сферического коня в вакууме" в виде голого процессора или сервер в целом ? > Можете сие опровергнуть? Могу. У Intel-овской архитектуры совершенно убогая реализация SMP (тут уже говорили, что более 4 CPU - это извраты на тему cluster in box). Плюс ко всему у SUN-овских серверов более производительная подсистема ввода/вывода, что для Oracle более критично, чем быстрый CPU. | |
| | |
| Mikhail Elashkin - imhoelashin.com 15 Mar 2006 10:36 AM |
| 2 xxx Я соглашусь. Xeon это не процессор для серьезных СУБД задач. | |
| | |
| Бармаглот 15 Mar 2006 3:11 PM |
| 2ххх: "У Intel-овской архитектуры совершенно убогая реализация SMP (тут уже говорили, что более 4 CPU - это извраты на тему cluster in box). Плюс ко всему у SUN-овских серверов более производительная подсистема ввода/вывода, что для Oracle более критично, чем быстрый CPU." - это не опровержение, а догматичное, ни единым фактом не подкрепленное заявление, в просторечье называемое - 3.14здеж | |
| | |
| Mikhail Elashkin - imhoelashin.com 15 Mar 2006 3:35 PM |
| 2 Бармаглот А могу я спросить чем вы обосновываете свое утверждение? Ну просто чтобы иметь представление... | |
| | |
| Desperado 15 Mar 2006 4:41 PM |
| подверждаю, однозначно 3.14дешь. бимерский 16-way xeon в tpc-c показывает 492 tps, последний 16-way power5 809 tps, SUN нивжизнь непотянет и половины от результа power5, т.е. однозначно недотянет и до 400 tps. | |
| | |
| Desperado 15 Mar 2006 4:50 PM |
| а в tpc-h@1000 GB 4-way оптероны рвут новейшие 4-way спарки в разы :) | |
| | |
| Pers 15 Mar 2006 6:44 PM |
| 2Прохожий +++ Ты всегда так тщательно сможешь спланировать что у тебя под какой нагрузкой будет работать через несколько лет? +++ ну работа такая :) предприятие у нас специализированное - изменения направлений деятельности не ожидается как минимум до 20х годов. И планирование ВЦ делается по старой привычке на 5 лет. +++ Если специализированные машины СУЩЕСТВЕННО лучше машин общего назначения, тогда нет смысла брать машины общего назначения. Но так ли это на самом деле? +++ уточни, в каких случаях? если специализированую машину использовать в ее специализированной области - она будет лучше машины общего назначения? неужели есть сомнения? на счет мнения IBM. ну что ж - уважаемая организация. Но наши задачи на кластере из 32 2х процессорных нод на Оптеронах быстрее посчитались, чем на Ксеонах. Выигрыш - 27%. | |
| | |
| Бармаглот 16 Mar 2006 1:25 PM |
| 2M.Елашкин: напишу, отчего ж не написать. Итак, некто ххх пишет что для его задач используется следующее оборудование - 24 US3Cu/192 GB/16 TB, и заявляет, что "Интел рядом не валялся". Вероятнее всего, это биллинг у сотового оператора, но может быть и другая OLTP+BI помесь. Идем на сайт tpc.org и смотрим. по TPC-C напрямую не сравнить, к сожалению, по TPC-H смотрим конфиги, соответствующие условиям задачи На 3000 GB имеем два рядом стоящих результата от 2004 года - Супердом о 64 Итаниумах с результатом 45247 и Фуджи с 64 СПАРКами (кстати более производительными чем US3Cu) с результатом 34345. Интел действительно рядом не валялся. Он на 30% быстрее... Можно и дальше сравнивать, более новые системы и процы. Результат все равно будет примерно таким же. Кстати вот вышел первый TPC-C на Монтесито... 200 ktpm-C на 2 процах (4 ядрах)... неплохо для начала... | |
| | |
| Mikhail Elashkin - imhoelashin.com 16 Mar 2006 8:22 PM |
| 2 Desperado >подверждаю, однозначно 3.14дешь. бимерский 16-way xeon в tpc-c показывает 492 tps, последний 16-way power5 809 tps, SUN нивжизнь непотянет и половины от результа power5, т.е. однозначно недотянет и до 400 tps Можно только в порядке ведения собрания. Sun перестал делать тесты ТРС-С уже лет 5-6 как. Причем ушел имея рекорды в этом деле. Логика в их решении есть - сегодняшние процессоры засасывают код теста в кэш и фактически ТРС-С тестирует производиетльность заказчивания данных их памяти в кэш, а не общую производительность. Я не полностью с ними согласен, но считаю, что единственный сегодня правильный тест для железа это SAP SD 2-tier Так что все-таки не надо сравнивать производительность с теми, кто в этой категории принципиально не выступает. | |
| | |
| Mikhail Elashkin - imhoelashin.com 16 Mar 2006 8:29 PM |
| 2 Бармаглот я что-то пропустил? почему именно 3000G тесты? ну хорошо, смотрим и видим, что там лидер абсолютный это Sun Fire[TM] E25K server 105,430 QphH ближайший интел (причем Itanium, а не х86) HP Integrity Superdome Enterprise Server 71,847 QphH Действительно разница на 30%, но в пользу SPARC Ну и по процессорам там 72 SPARC и 64 Itanium близко. По крайней мере цена за транзацкии Price/QphH у СПАРКа лучше. 54.87 US $ у него против 56.00 US $ у Итаниума. | |
| | |
| Прохожий 16 Mar 2006 9:31 PM |
| Для Pers ну работа такая :) предприятие у нас специализированное - изменения направлений деятельности не ожидается как минимум до 20х годов. И планирование ВЦ делается по старой привычке на 5 лет. --- Я тебе завидую. У нас так не получится, увы. Рост чересчур буйный и ситуация вокруг мало предсказуемая. уточни, в каких случаях? если специализированую машину использовать в ее специализированной области - она будет лучше машины общего назначения? неужели есть сомнения? --- Конечно есть сомнения. В случае тех же АппСерверов. Далеко не факт, что Ниагара будет там лучше тех же Ксеонов при относительно небольшом количестве процессоров (до 16 включительно). Если это не так, готов выслушать ваши обоснованные ссылками на тесты (а не умозрительные) доводы. Мне действительно интересно. | |
| | |
| Прохожий 16 Mar 2006 9:36 PM |
| Для xxx Для ваших клиентов - это одно. Но ваши клиенты насколько показательны. Вот данные из того же TPC-H. 100Gb SunFire V490: Metric - 6,433 QphH@100GB Total System Cost - 143,471 US $ PowerEdge 6800/32G/3.0GHz/2+2MB Metric - 8,793 QphH@100GB Total System Cost - 75,519 US $ | |
| | |
| Прохожий 16 Mar 2006 9:44 PM |
| То есть можно сказать, что преимущества Сан начинают проявляться только начиная с определенных объемов данных и определенного количества процессоров. Насколько я понял - это достаточно дорогие машины и достаточно большие объемы данных. В мелких серверах Сан уступает несколько по производительности и очень сильно по цене. | |
| | |
| Прохожий 16 Mar 2006 9:48 PM |
| Жаль только, что программное обеспечение, которое установлено на младшем Сановском сервере не совпадает с программным обеспечением на том же Делл. Ибо от этого результат тоже сильно зависит. | |
| | |
| Desperado 16 Mar 2006 10:08 PM |
| >ну хорошо, смотрим и видим, что там лидер абсолютный это Sun Fire[TM] E25K server 105,430 QphH ближайший интел (причем Itanium, а не х86) >Так что все-таки не надо сравнивать производительность с теми, кто в этой категории принципиально не выступает. двойные стандарты однако. да и повторю тезис Бармаглота "это не опровержение, а догматичное, ни единым фактом не подкрепленное заявление, в просторечье называемое - 3.14здеж" | |
| | |
| Михаил Елашкин - imhoelashkin.com 17 Mar 2006 9:29 AM |
| 2 Desperado чего-то вы ребята глючите... я потерял вообще нить вашей логики (если она вообще была) | |
| | |
| Бармаглот 17 Mar 2006 3:17 PM |
| 2M.Елашкин: Попробую восстановить. Есть задача. Дано решение (USIII и т.д.)+утверждение "Интел рядом не валялся". Приведено аргументированное опровержение. Поясню опровержение еще раз. ххх не указал тип задачи полностью, поэтому было сделано предположение, что это OLTP + гоняемый по этой же базе BI. На всех 16 ТВ BI они не гоняют, аналитика делается по меньшим объемам. посему взят тест TPC-H ближайший по: - типу задачи - возрасту оборудования - типу конфигурации. Если остались вопросы - милости прошу. Теперь относительно абсолютных рекордов. Да, есть результат на 72 процах (144 ядрах) от САН, лучший на сей момент. При количестве ядер в 2.25 раз больше показан результат в 1.47 раз больше. Т.е. одно ядро СПАРК = 0.65 ядра старого Мэдисона. (опять разница в пользу Интел) Напомню также, что большЕЕ количество ядер несет большие лицензионные траты. Ну и т.д. | |
| | |
| Михаил Елашкин - imhoelashkin.com 17 Mar 2006 3:31 PM |
| 2 Бармаглот > Напомню также, что большЕЕ количество ядер несет большие лицензионные траты цена за транзацкии Price/QphH у СПАРКа лучше. 54.87 US $ у него против 56.00 US $ у Итаниума | |
| | |
| Pers 17 Mar 2006 3:54 PM |
| 2Прохожий +++ Конечно есть сомнения. В случае тех же АппСерверов. Далеко не факт, что Ниагара будет там лучше тех же Ксеонов при относительно небольшом количестве процессоров (до 16 включительно). +++ Зачем сваливаться в конкретику, если говорим о идее. Ну ладно - представть машину специализированое до самого нехочу для имено твоих АппСерверов. Как думаеш - кто будет работать лучше - специализированная машина или машина общего назначения :-) На счет неагары - я сомневаюсь, что она потянет АппСервера. Все таки там логика присуствует, и иногда серезная. Хотя АппСерв АппСерву рознь. А ниагара - позиционируется как телекоммуникационный сервер. +++ Если это не так, готов выслушать ваши обоснованные ссылками на тесты (а не умозрительные) доводы. +++ А как же без умозрения то? Оно то первично, а цифирь вторична. Сначало нужно подумать, а потом на цифирь смотреть. | |
| | |
| Михаил Елашкин - imhoelashkin.com 17 Mar 2006 4:15 PM |
| Пара уточнений. Ниагара (Т1) это один процессор. Будет еще его вторая линия, когда можно будет ставить не один, но не скоро. Так что один процессор с 8 ядрами. Кроме того, Т1 никак не коммуникационный севрер - кто это вам сказал? Это сервер для задач с множеством потоков. | |
| | |
| Pers 17 Mar 2006 7:28 PM |
| да, ниагара процессор для задач со множеством потоков. однако нужно определиться какие имено задачи. Задачи в основном телекоммуникационные, отработка простых потоков. Что характерно скажем для Web-серверов, служб каталоков, кэшей и т.д. Несколько удивляет настойчивое позиционирование для java. Я конечно не специалист в Java, но мне думается для него нужна не только целочисленная математика. В процессоре как уже говоилось, только один модуль для вычислений с плавоющей точкой. А без этого сегодня сложную задачу не запустить. | |
| | |
| Михаил Елашкин - imhoelashkin.com 17 Mar 2006 9:00 PM |
| 2 Pers по поводу задач сошлись единственно, что абсолютное большинство бизнес задач сегодня не требуют плавающей точки. ну нафиг она в СУБД? | |
| | |
| fi 21 Mar 2006 12:12 PM |
| > ну нафиг она в СУБД? Я тоже задался таким вопросом, но тем не менее libm для oracle требуется. В Pg я нашел рассчет оптимизации, возможно и в oracle тоже самое. | |
| | |
| Михаил Елашкин - imhoelashkin.com 21 Mar 2006 12:46 PM |
| 2 - fi нет, плаавющая арифметика в СУБД есть, но используется очень редко, только при работе с числами... | |
| | |
| Прохожий 21 Mar 2006 1:21 PM |
| Для Pers Зачем сваливаться в конкретику, если говорим о идее. Ну ладно - представть машину специализированое до самого нехочу для имено твоих АппСерверов. Как думаеш - кто будет работать лучше - специализированная машина или машина общего назначения --- Мои АппСервера могут один раз так работать, другой раз иначе работать. То есть задачи таковой (АппСервера) как таковой нет. Поэтому до сих пор неясно сама возможность "специализации" под такого рода "задачи". | |
| | |
| Прохожий 21 Mar 2006 4:11 PM |
| А как же без умозрения то? Оно то первично, а цифирь вторична. Сначало нужно подумать, а потом на цифирь смотреть. --- Думать, оно, конечно, не помешает. Но можно иной раз ТАКОГО надумать... В данном конкретном случае я предпочту цифирь безсмысленным размышлениям. | |
| | |
| Михаил Елашкин - imhoelashkin.com 21 Mar 2006 6:21 PM |
| 2 Прохожий Единственное общее что должно быть у серверов приложений это наличие множества потоков. Т.е. если сервер приложений в какой-то момент так изменится, что станет выполнять только одну задачу в один поток, то тогда конечно... но это сильно вряд ли ) | |
| | |
| The Member 25 Mar 2006 8:52 AM |
| вброс.. Поток - не более чем средство повышения КПД ядра ("многоядерный процессор" - это бред слабо образованных маркетологов, которые видимо когда-то путали процессор i286 с гудящим ящиком, на котором стоит монитор. Архитектурно это разные устройства - я 2-4-8 итд ядер - не более чем упаковка.) Так собственно - потоки на ядре могут и не спасать - так как их эффективность зависит от вынужденного простоя ядра по памяти и прочих задержек обусловленых и архитектурой и структурой самого потока. Равно как 4 взрослых человека будут испытывать сложности при одновременной еде из одной тарелки на скорость, а 8 тараканов - никаких. Поэтому 8 ядер USII с одним модулем плавающей точкит на всех, 3МБ L2 кэш (на 32 (!) потока, с не очень глубокой ассоциативностью) с приклееным сверху шильдиком T1 - не являетя исполнителем универсальных потоков. Особенно создаваемых реальными базами данных. | |
| | |
| iafltj rjtwsa - jhqvesmail.com 22 Aug 2006 3:23 PM |
| ycwzptro lysbgpq guqfeoshx yhidrlfs bypgr zcaigueml jcvesadx | |
| | |
| iafltj rjtwsa - jhqvesmail.com 22 Aug 2006 3:23 PM |
| ycwzptro lysbgpq guqfeoshx yhidrlfs bypgr zcaigueml jcvesadx | |
| | |
| byoea awkhv - jxbsmail.com 22 Aug 2006 3:24 PM |
| vyibgx bgox lkrueoi ohrasqzcv hmulgafn zgjwk tsqx http://www.dgfh.nesam.com | |
| | |
| nrqyaij xbzncthg - wqkflxgmail.com 22 Aug 2006 3:25 PM |
| wytoaem utabeif gbyou ncomzg ryfhp ceulnrt vfhsw [URL=http://www.xymaortwh.tefmcq.com]wmbpcl vopdjukec[/URL] | |
| | |
| cuepvx viprzajgl - dbamyepnvmail.com 22 Aug 2006 3:25 PM |
| tpmroja petfgrbs lbmqjh mnktf kpvsyjg wevjcn opqwksamt [URL]http://www.mnzajhw.ibvptw.com[/URL] fmrghxu fxudohw | |
| | |
| Ares 25 Aug 2006 11:30 AM |
| В Desperados 2 люди переливаются разными цветами, то красным, то розовым, то зелёным и т. д., что делать. | |
| | |
| ← февраль 2006 | 2 3 6 7 9 10 13 14 15 | апрель 2006 → |
Место для Вашей рекламы!