Исходное сообщение
"Разработчики OpenOffice.org создали независимый форк проекта..." Отправлено zerot, 28-Сен-10 22:22
упрощённо - помедленнее в вычислительных операциях для сопоставимой частоты камней . из моего практического опыта - например двухпроцессорный Sun Fire (SF) 240 второго поколения (с камнями 1500Mhz) несколько медленнее аналогичного двухпроцессорного сервера x86 с аналогичной частотой - на задачах, связанных с СУБД Oracle и на коммуникационном функционале . что касается многопроцессорной архитектуры санового железа, то это совсем другая специфика - здесь обеспечивается не более быстрое вычисление, но одновременная работа нескольких параллельных сессий. Из моего практического опыта - up48 процессорный SF6900 довольно спокойно обеспечивал функционирование АБС в Москвы и области для крупного ТОП-30 коммерческого банка. Именно за счёт специфики нагрузки, грамотно реализованной прикладной части и многопроцессорной конфигурации . Если же говорить об относительно новых камнях типа ниагары, то их архитектура тоже довольно специфична и заточена под определённые виды нагрузки. Насколько я помню там используется "разделяемый кэш", так что это не совсем честные 16 (опять же насколько помню) - процессорные камни. Но таки это лучше обсуждать со спецами - железячниками, ибо от меня оно щас далеко . лицензирование, применяемое ораклом, на мой взгляд довольно агрессивное вообще. В том числе лицензирование по сокетам с уточняющими коэффициентами для каждой архитектуры тоже отражает некую жадность, да. И уменьшающий коэффициент для сановых камней появился не на пустом месте, стал бы Оракл вводить его просто так. Но пока альтернативы этой СУБД не вышли на конкурентный уровень ...