Скрытые вычисления: точки привязки

В одной из прошлых заметок я писал (правда, больше в шутку) о скрытых (навязанных) вычислениях, которые могут проводить распространённые ОС в рамках процедуры получения обновлений. Результаты этих вычислений, понятно, могут использоваться производителями ОС: грех же не воспользоваться миллионами бесплатных часов машинного времени.

Интересно, что навязать пользовательскому компьютеру такие вычисления можно и без доступа к системе обновлений. Логичное решение – посещаемый веб-сайт. Конечно, можно что угодно запрограммировать на JavaScript и отправлять результаты подсчётов на сервер после загрузки страницы, или даже считать всё время, пока страница загружена, а результаты отправлять асинхронно, с помощью AJAX. Но JavaScript – медленный, да и решение получается слишком банальное.

Изящное решение могло бы быть вот каким: навязанная вычислительная задача “зашивается” в рендеринг веб-страниц. Например, когда браузер размещает в окне визуальные блоки, определяемые специально подготовленным CSS-ом (таблицами разметки страниц), он решает задачи, близкие к комбинаторным (ведь позиционирование блоков может быть относительным и абсолютным, с разной глубиной, с разным выравниванием и т.п.).

CSS-ы можно генерить разные при каждом обращении браузера. В каждый экземпляр CSS-ов транслируется кусочек задачи, кусочек навязанных вычислений. Получить информацию об итоговом расположении блоков сложнее, нужно привязывать всё к каким-нибудь фоновым картинкам. Возникают вопросы: кто-то уже такое делал? Выгодно ли это в вычислительном плане, относительно затрат на формирование CSS-ов?

()

Похожие записки:



Далее - мнения и дискуссии

(Сообщения ниже добавляются читателями сайта, через форму, расположенную в конце страницы.)

Комментарии читателей блога: 8

  • 1. 29th June 2010, 20:15 // Читатель A.I. написал:

    Кстати, JavaScript не такой уже и медленный, Google, Apple и Mozilla вкладывают огромное кол-во сил в его виртуальные машины и сейчас JS в Chrome в 3 раза быстрее Python и всего в 10 раз медленнее C ( http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=python&lang2=v8 ).
    Тем более новые браузеры (а чуть позже и IE) поддерживают многопоточность на JS (Web Workers) и OpenGL-вычисления (WebGL)

  • 2. 29th June 2010, 20:48 // Читатель kaschey написал:

    Подозреваю, что Adobe Acrobat постоянно меня объедает, что-то качает и вообще гадит в системе. Но вот на вопрос, извлекает ли из этого хоть какую-то пользу Adobe ответить не могу.

    :-)

  • 3. 29th June 2010, 20:54 // Читатель kaschey написал:

    Может я чего не так понял, но формирование хитрого HTML+CSS, отправка, прием, зашифровка-расшифровка данных, синхронизация и сборка совершенно нерациональны. Проще на месте вычислить.

  • 4. 29th June 2010, 21:19 // Читатель jno написал:

    Да уж – вернуть результат рендеринга…
    Впрочем, можно выполнить обход дерева DOM и отрепортить координаты и размеры.
    Относительно окна браузера будет.
    Но вот размеры того окна – они ж у всех разные!
    Можно и их отрепортить.
    А что мы поимеем? Решённую задачу раскладки блоков.
    Ладно.
    Хуже – то, что разные браузеры её по-разному решают.
    Тут уже воспроизводимость результатов поплывёт.

    Что-то из генетических алгоритмов?
    Надо подумать…

  • 5. 29th June 2010, 22:02 // Читатель Mad написал:

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

    Если задача звучит как “получить миллион(ы) часов вычислительного времени” будучи вендором популярного продукта, то я бы поступил следующим образом: внедрил в продукт какое-то анкетирование, занимающее 1-2 минуты пользовательского времени. И активно “пиарил” бы эту анкету, например раздавая призы среди заполнивших.
    Во время заполнения анкеты активность пользователя с т.з. вычислительных ресурсов минимальна, и в это время можно выполнить необходимый chunk вычислений. Далее, результаты анкетирования вместе с результатами вычислений объединяются в какой-то пакет и отправляются по https с приличной длины ключем.

  • 6. 30th June 2010, 09:20 // Читатель dign написал:

    Ну, тогда проще использовать плагины или ActiveX под броузеры. Вот их как раз пользователи ставят даже не задумываясь. А вы все о каких-то хитрых HTML и “супербыстрых” скриптах. :)

  • 7. 30th June 2010, 12:06 // Читатель sarin написал:

    можно использовать апплет для вычислений. или flash-плеер. flash меньше подозрений вызовет, java быстрее.

    заставить вычислять браузер через рендеринг, конечно можно, но оверхед боюсь всё съест. даже голый JavaScript представляется более выгодным решением.

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

  • 8. 30th June 2010, 12:25 // Читатель jno написал:

    > проще использовать плагины или ActiveX

    ActiveX есть только на одной платформе…

    > верным может быть только, например, решение IE.

    “учение Маркса всесильно…”(С)Ульянов

    для тех же генетических (и, вероятно, других “переборных”) алгоритмов разброс браузеров – плюс.
    другое дело, что тот разброс имеет неравномерное распределение, что надо будет учитывать как-то при сборке результата.

    а так-то обычный мап/редьюс можно на этом деле смастерить.