Эволюция графики

Вопрос в другом - почему на процессоре, на котором можно успешно моделировать белок для лечения рака тормозит форма ввода сообщений?

Может потому, что алгоритм по которому идет моделирования белка проще, чем алгоритмы по которым работает форма ввода сообщений?

Нет. Просто у тех, кто писал программу для белков, руки прямее

Ну да, ну да, конечно!
Мы конечно не будем учитывать, что у браузера на вход идут почти всегда кривые данные, что на одной странице могут быть по 100 картинкок/js/css с 20 разных доменов, что работать он должен на совершенно разном железе и при этом желательно не быть решетом, а значит нужно все изолировать, что дает огромнейший оверхед.

Конечно! Это разработчики браузеров криворукие, а не верстальщики, кодеры и писатели стандартов которые плевать хотели на потребление ресурсов.

Может потому, что алгоритм по которому идет моделирования белка проще, чем алгоритмы по которым работает форма ввода сообщений?

Базовый алгоритм, по которому идёт сворачивание белка - O(n^2*t) или O(n^3*t) в зависимости от типа потенциала. Разными разбиениями пространства и оптимизациями можно свести его к O(n*t). Нормально сделать то же самое на GPU ещё сложнее, я проверял.

А вот как сделать сложность обработки GUI выше линейной, я что-то не представляю.

GUI никто не оптимизирует :)

в Дельфи (4-7?) выпадающие списки в GUI были статическими массивами с максимальной длиной. Т.к. в Дельфи не было нормальных коллекций, вместо них люди создавали в памяти выпадающие списки, и использовали их как коллекции. Естественно, на экране они не рисовались, но все равно все тормозило ппц. Особенно забавно, когда люди использовали «невизуальный» выпадающий список как контейнер промежуточных данных для вывода в нормальный список, рисующийся на формочке.

например, писали мы как-то словарик для мобилок. Тупо поиск слова из списка. Половина конкурентов тормозит адски. Так можно тормозить только если хранить слова в несортированном виде, и искать линейным поиском. Или сортировать пузырьком прямо в рантайме. Ну или вот по этой причине: http://habrahabr.ru/post/146228/. Мы делали предкомпилированные сортированные словари, в которых можно искать бинарным поиском, в результате скорости мобилки хватило даже на то, чтобы искать слово и перерисовывать список слов, прямо в момент ввода, без нажатия кнопочки «поиск» каждый раз.

Это разработчики браузеров криворукие, а не верстальщики, кодеры и писатели стандартов которые плевать хотели на потребление ресурсов.

Где-то в треде кто-то говорил, что «верстальщики, кодеры» НЕ криворукие? Не говорил? Тогда с чем ты тут споришь?

Индекс целиком в памяти был?

Бд ручками своя, на random access files - вот это секрет успеха. Парочка скомпилированных индексов на диске, состоящих из нескольких файлов, индексы поверх индексов (плюс помойму была статистика по часто ищущимся словам). В памяти не полный индекс, памяти не хватит, а что-то типа небольшого кэша, иногда подсказывающего в поиске.

Т.к. в Дельфи не было нормальных коллекций, вместо них люди создавали в памяти выпадающие списки

4.2. Кое-кто просто свелосипедил нужные структуры данных сам.

в Дельфи не было нормальных коллекций

Списки были вообще-то.

Невизуальный выпадающий список — это TStringList что-ли?

Ясно, спасибо.

Помойму, компонент назывался ListBox. С точки зрения фимозников, использующих компоненты как коллекции, отличался от ComboBox тем, что там можно было выбирать диапазон элементов. Но это было очень давно, возможно, все наврал :(

Т.е. на страничке в интернетах «картинок» больше, чем при отрисовке какой-нибудь 3-d демки? А ещё там те же эффекты. И функционал такой же.

Я до сих пор понять не могу, почему у меня в системе брозеёр собирается дольше и весит больше, чем весь остальной софт. Даже вместе.

Или на него не давили и не говорили, что белок надо было смоделировать вчера.

И да, обработка формы всё-таки больше подсистем задействует в принципе.

Вот вы всё и сказали своим посттом. В моделировании белка есть один базовый алгоритм, и всё. В обработке ввода в форму куда больше, плюс неустранимые и в принципе отстуствующие при моделировании белка задержки на связь с сервером.

А вот как сделать сложность обработки GUI выше линейной, я что-то не представляю.

Сложность парсинга и JIT-компиляции javascript выше линейной.

Т.е. на страничке в интернетах «картинок» больше, чем при отрисовке какой-нибудь 3-d демки?

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

А браузеру надо все делать на лету, с учетом медленного железа, медленного dns, медленной сети, кривых входных данных.

В моделировании белка есть один базовый алгоритм, и всё.

Как бы не так. Каждый тип потенциала — свой алгоритм: EAM, bond-order, всякие CTIP друг от друга отличаются как небо и земля. Для близкодействующих потенциалов — один алгоритм суммирования. Для дальнодействующих с периодическими гранусловиями — другой. Для дальнодействующих с непериодическими гранусловиями — третий. Всё это может присутствовать в модели одновременно. Каждый fix — тоже свой алгоритм.

и в принципе отстуствующие при моделировании белка задержки на связь с сервером.

Правда что ли? MPI в молекулярной динамике — это такая головная боль, которую я пока даже не пытался осилить.

Сложность парсинга и JIT-компиляции javascript выше линейной.

Но это же один раз должно по идее делаться, при загрузке страницы.

С точки зрения фимозников, использующих компоненты как коллекции

То, действительно, какие-то фимозники были. В 6-7 дельфи были и коллекции (TList с потомками), и динамические массивы и указатели.