информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
За кого нас держат?Где водятся OGRыSpanning Tree Protocol: недокументированное применение
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Крупный взлом GoDaddy 
 Просроченный сертификат ломает... 
 Phrack #70/0x46 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / dnet
Имя Пароль
ФОРУМ
все доски
FAQ
IRC
новые сообщения
site updates
guestbook
beginners
sysadmin
programming
operating systems
theory
web building
software
hardware
networking
law
hacking
gadgets
job
dnet
humor
miscellaneous
scrap
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
:) Давайте к делу - регистрация. 19.11.02 09:34  Число просмотров: 1814
Автор: Konstantin Leontiev Статус: Незарегистрированный пользователь
<"чистая" ссылка>
> [...]
> > Ну а на чём же ещё клиент строить.<
>
> не берусь давать советы по этой теме (совсем вне моей
> компетенции - могу и глупость ляпнуть, так что не
> обезсудьте), а на уровне идеи, мне кажется, что клиент
> должен быть простым "числогрызом" с предельно
> оптимизированным ядром (точнее ядрами под разные процесоры)
> и видимо, на ассемблере, иначе то как (или я опять чего-то
> не догнал?) + модуль алгоритмов проектов (или ядра под
> каждый проект отдельно, что наверняка эффективнее, но
> тогда: "кол. ядер" = "кол. проц." * "кол. проект") +
> комуникационный модуль и всё. получать он должен данные,
> подготовленные в какой то канонической форме, подставлять
> их и сохранять результат, опять в канонической форме.
> буфера обновить и подобное - оно понятно. т.е. никакого
> анализа или понятий о предметной области.
> а исследовательский софт (как я его понимаю) в первую
> очередь должен позволять менять исходные данные и
> анализировать результаты счёта, а по результатам анализа,
> давать рекомендации для изменения исх. данных, т.е.
> собственно счёт в нём очень небольшой кусок, без него,
> понятно, не обойтись, но не он во главе угла.

Это рассуждение приемлемо для клиента RC5. Но не для клиента вычислящего молекулярную динамику. Дело втом что в методе МД на каждом шаге интегрирования (а таких обычно около 10 000 000) интегрируется система диференциальных уравнений второго порядка, которая состоит в зависимости от размера молекулярной системы примерно из 15 000 уравнений с сильно не линейной левой частью. Прямым следствием такого интегрирования является траектория (зависимость координат каждого атома от времени). В обычных пакетах МД такие траектори заннимают сотни мегабайт, а в иных случаях и несколько ГБ. Поэтому сделать распределённые вычисления на GROMACS например или на NAMD невозможно. Они слишком много будут отъедать дискового пространства у доноров.

Наше же ноу-хау состоит в том, что мы не пишем траекторию в файл результата а по мере интегрирования уравнений сразу же вычисляем необходимые для дальнейшего исследования статистические величины. Эти файлы занимают в сотни и тысячи раз меньше места чем файлы траекторий. Они потом упаковываются (поскольку они текстовые) и отправляются на сервер.

Так вот по моиму писать на ассемблере модуль решения системы диф. уравений это мазохизм, а вот промежуточные процедуры работы с матрицами и с векторами - самое милое дело. Боее того что касается производительности нашего ядра - мы исследовали этот вопрос весьма тщательно и можем гориться тем, что она даже на C написано очень оптимально и выжимает из системы всё что можно.
<dnet> Поиск 








Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2021 Dmitry Leonov   Page build time: 1 s   Design: Vadim Derkach