|
ru.linux- RU.LINUX --------------------------------------------------------------------- From : Oleg Drokin 2:5020/400 08 Dec 2005 17:06:51 To : "U.P.Galyuck" Subject : Re: LinuxWay --это куда? -------------------------------------------------------------------------------- u> <dn4kdg$c6t$1@car.linuxhacker.ru> <dn6adt$ble$1@news.spbu.ru> u> <dn6mqo$ler$1@car.linuxhacker.ru> <dn6ucq$jog$1@news.spbu.ru> u> <dn74vf$nef$1@car.linuxhacker.ru> <dn8rb6$1d6b$1@news.spbu.ru> u> <dn947d$vhl$1@car.linuxhacker.ru> <dn96bj$1hr1$1@news.spbu.ru> From: Oleg Drokin <green@linuxhacker.ru> Hello! U.P.Galyuck <galyuck@paloma.spbu.ru> wrote: >> UPG> средних по возможностям предприятий/вузов и оптимальных по >> соотношению >> UPG> цена/производительность. >> Сюрприз-сюрприз - подход примененный в "монстрах" из top500 прекрасно >> подходит >> и для построения более мелких решений, просто число cpu будет поменьше. >> При этом в случае необходимости нормальные решения нормально >> масштабируются UPG> Вы абсолютно уверены в своих словах? Вот я точно знаю, что обратное HЕ Угу. UPG> ВЕРHО. А именно - решения, хорошо зарекомендовавшие себя на малых размерах С этим спорить не буду ;) UPG> оказываются неприменимыми в больших масштабах (переход "количества" в UPG> "качество"). Я не вижу причин, почему это правило не должно работать при UPG> переходе от большого к малому, хотя бы из-за того что работают разные UPG> критерии оптимальности, к примеру, на малом кластере не нужна сверхбыстая UPG> сеть и т.п. Hа большом кластере сверхбыстрая сеть тоже необязательна. Все зависит от задач. Примеры задач, где сверхбыстрая сеть не требуется уже приводились. Или речь об оптимальности только цены? Так все равно если для задачи требуется быстрая сеть, то даже для "кластера" из двух нод нельзя использовать gige или 10gige, просто потому что у них чудовищная latency (а если к жтому прибавить tcp то и вовсе вешайся). И все равно прийдется ставить какой нить elan, infiniband и прочие myrinet'ы. Какие еще "т.п." предложите? Или единственным критерием выберем цену? О возможностях дальнейшего легкого масштабирования и быстрого интерконнекта, простоте обслуживания забудем как о ненужных? UPG> Да, и нельзя ли вам в дальнейшем использовать более мягкие утверждения, UPG> потому что обороты типа "подход примененный в "монстрах" из top500 UPG> прекрасно подходит и для построения более мелких решений" без ремарки "как UPG> мне кажется" или "я думаю, что" подразумевают абсолютную уверенность в UPG> написанном, что вряд ли имеет место в действительности, т.к. как минимум Почему? UPG> предполагает работу в отделе по разработке суперкомпьютеров в фирме ИБМ в UPG> качестве ведущего инженера, и знание результатов тестирования на UPG> соответствующем спектре оборудования. Hу я, конечно, не в IBM работаю, но в том числе и мой код на BG/L бегает. И на более мелких машинках он же прекрасно бегает. Так что некоторое представление я все же имею. Bye, Oleg --- ifmail v.2.15dev5.3 * Origin: Green's home news server (2:5020/400) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /ru.linux/155502be38374.html, оценка из 5, голосов 10
|