![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
в поисках виртуальной машины
пока меня поразило устройство двух виртуальных машин
- Macromedia/Adobe Flash AVM2 (эволюция превратила маленькую кавайную зверушку в огромного хаотичного монстра)
- виртуальная машина PyPy (концептуально и круто, и, эмм, ест моск. очень сильно ест моск)
что ищется в первую очередь:
- code serializaltion [a.k.a. serialize(eval(‘lambda x, y: x+y’)) ]
- thread serialization (tasklets, threadlets, кто как называет)
- контроль над исполнением потоков (ручной scheduler и\или управляемое preemptive multitasking)
- наличие интерпретатора\компилятора языка высокого уровня под данную VM
- работающего под ней же ;)
что было бы прикольно иметь:
- в идеале – замкнутость, т.е. чтобы внутри этой VM можно было запустить экземпляр такой же VM, но это не обязательно
- code instrumentation (как минимум _pentry/_pexit, в идеале – встроенный profiling)
- встроенный debugger было бы без сомнения круто, но в случае чего его можно и дописать
- еще интересна рефлексия программы и\или рефлексия самой VM.
- быстродействие вторично, но все же лучше, чтобы скорость не отличалась более чем в 1000 раз от кода на C
UPD: еще одно применение thread serialization - для ускорения запуска тяжелых программ (fread+memcpy явно быстрее загрузки чего-либо, даже тривиального), вспомнил после прочтения http://zhengxi.livejournal.com/73471.html
no subject
no subject
ну это да :)
ну то есть в идеале замкнутость означает, что VM должна иметь возможность еще и пересобрать саму себя в бинарник для таргет платформы, но вроде таким может похвастаться только pypy, да и то с привлечением нетривиального количества сторонних инструментов :)
>> если я, конечно, правильно понимаю критерии
Важно иметь:
- "убить thread" (т.е. именно preemptive abort)
- "сериализовать thread"
- "запустить поток на N миллисекунд и потом остановить на M миллисекунд"
- последний параметр обобщается как "задать квоты ресурсов для потока"
no subject
no subject
no subject
- обычно у таких штук много state
- хочется понизить планку требований к программисту бота, чтобы ботов и скриптов было много, хороших и разных. да и просто ускорить разработку :)
- поэтому отпадает вариант написания кода, который сам заботится обо всём state
- если агентов на одной машине наплодится много, хочется перетащить нагрузку на вторую машину. или если надо перезапустить VM, мало ли, например сервер дешевый и горячую замену железа не использует. или если хочется держать взаимодействующие кластеры ботов поближе друг к другу
- алгоритмы работы агентов пишутся другими людьми, поэтому доверия к ним нету, а обрушивать сервер сжиранием ресурсов по ошибке или преднамеренно они права не имеют
ах да, сериализовать поток еще удобно если хочется hibernate в пределах отдельно взятой пользовательской программы, например :)
no subject
no subject
Эрланг как вариант, да.
Опять же, интересует, как будут вести себя все эти штуки, если на машине будет, скажем, 100к потоков (которые в основном спят, но иногда просыпаются и могут выполнять долгоиграющие действия)
Цель - уменьшить максимальное response time, возможно, за счет увеличения среднего. Т.е. если из 1000 запросов один займет секунду, а остальные 2 мс, то это плохо. Если все займут по 20 мсек, то это хорошо (невзирая на то, что общая загрузка будет выше и все такое)
no subject
as a completely unrelated note, пора спать, а то меня сейчас начнет заносить в бред
no subject
no subject
а размышления это на тему "как может выглядеть движок для" -> http://wizzard0.livejournal.com/26452.html
записи будут помечаться тэгом "муравьи"
no subject
no subject
no subject
no subject
no subject
no subject
no subject
*** кстати, вроде, подобными извращениями с высоконагрузочным реалтаймом еще занимаются товарищи в last.fm - у них нагрузки порядка миллионов реквестов на запись в секунду (когда скробблер определяет, что пользователь прослушал трек), но там сильно однообразнее и возможно проще операции, которые они с данными делают
no subject
no subject
писать end-user code - имелся в виду не код, написанный пользователями, а код, исполняющийся у пользователя.
no subject
а то чем дальше, тем меньше понятно
no subject
мыслей скопилось вроде достаточно, чтобы не было слишком уж больших неопределенных пятен.
главная проблема с пониманием меня в том, что меня ответы уводят от оригинального контекста в размышления в духе "о, а ведь может случиться и такая ситуация, что же делать тогда?", которые расширяют область мира, который нужно захватить (с), и я отвечаю "блин, но ведь тут есть такое ограничение", которое не факт что применимо к оригинальной идее
я с этим стараюсь бороться, но не всегда получается (((
вообщем, завтра...
no subject
no subject
а пользователей у них порядка 30 млн
no subject
хиты с вебплееров (флэш-вставки), кстати, тоже засчитываются
но это оффтопик)
no subject
опять же, если я правильно понимаю проблему. по-моему всё же неправильно
no subject
а также общеизвестный факт что выход из hibernate быстрее загрузки системы+набора прикладного ПО, что линуха, что виндов
no subject
no subject
(Anonymous) 2009-05-15 10:48 pm (UTC)(link)no subject