Linear congruency considered harmful

Recently I stumbled upon this Stack Overflow question. The question author was puzzled with why he doesn’t see any improvement in the resultant value of \(\pi\) approximated using a parallel implementation of the well-known Monte Carlo method when he increase the number of OpenMP threads. His expectation was that, since the number of Monte Carlo trials that each thread performs was kept constant, adding more threads would increase linearly the sample size and therefore improve the precision of the approximation. He did not observe such improvement and blamed it on possible data races although all proper locks were in place. The question seems to be related to an assignment that he got at his university. What strikes me is the part of the assignment, which requires that he should use a specific linear congruential pseudo-random number generator (LCPRNG for short). In his case a terrible LCPRNG.

An inherent problem with all algorithmic pseudo-random number generators is that they are deterministic and only mimic randomness since each new output is a well-defined function of the previous output(s) (thus the pseudo- prefix). The more previous outputs are related together, the better the “randomness” of the output sequence could be made. Since the internal state can only be of a finite length, every now and then the generator function would map the current state to one of the previous ones. At that point the generator starts repeating the same output sequence again and again. The length of the unique part of the sequence is called the cycle length of the generator. The longer the cycle length, the better the PRNG.

Linear congruency is the worst method for generating pseudo-random numbers. The only reason it is still used is that it is extremely easy to be implemented, takes very small amount of memory, and it works acceptably well in some cases if the parameters are chosen wisely. It’s just that Monte Carlo simulations are rarely that cases. So what is the problem with LCPRNGs? The problem is that their output depends solely on the previous one as the congruential relation is

\begin{equation*} p_{i+1} \equiv (A \cdot p_i + B)\,(mod\,C), \end{equation*}

where \(A\), \(B\) and \(C\) are constants. If the initial state (the seed of the generator) is \(p_0\), then the i-th output is the result of \(i\) applications of the generator function \(f\) to the initial state, \(p_i = f^i(p_0)\). When it happens that an output repeats the initial state, i.e. \(p_N = p_0\) for some \(N > 0\), the generator loops since

\begin{equation*} p_{N+i} = f^{N+i}(p_0) = f^i(f^N(p_0)) = f^i(p_N) = f^i(p_0) = p_i. \end{equation*}

As is also true with the human society, short memory leads to history repeating itself in (relatively short) cycles.

The generator from the question uses \(C = 741025\) and therefore it produces pseudo-random numbers in the range \([0, 741024]\). For each test point two numbers are sampled consecutively from the output sequence, therefore a total of \(C^2\) or about 550 billion points are possible. Right? Wrong! The choice of parameters results in this particular LCPRNG having a cycles length of 49400, which is orders of magnitude worse than the otherwise considered bad ANSI C pseudo-random generator rand(). Since the cycle length is even, once the sequence folds over, the same set of 24700 points is repeated over and over again. The unique sequence covers \(49400/C\) or about 6,7% of the output range (which is already quite small).

A central problem in Monte Carlo simulations is the so called ergodicity or the ability of the simulated system to pass through all possible states. Because of the looping character of the LCPRNG and the very short cycle length, there are many states that remain unvisited and therefore the simulation exhibits really bad ergodicity.  Not only this, but the output space is partitioned into 16 (\(\lceil C/49400\rceil\)) disjoint sets and there are only 16 unique initial values (seeds) possible. Therefore only 32 different sets of points can be drawn from that generator (why 32 and not 16 is left as an exercise to the reader).

How this relates to the bad approximation of \(\pi\)? The method used in the question is a geometric approximation based on the idea that if a set of points \(\{ P_i \}\) is drawn randomly and uniformly from \([0, 1) \times [0, 1)\), the probably that such a point lies inside a unit circle centred at the origin of the coordinate system is \(\frac{\pi}{4}\). Therefore:

\begin{equation*} \pi \approx 4\frac{\sum_{i=1}^N \theta{}(P_i)}{N}, \end{equation*}

where \(\theta{}(P_i)\) is an indicator function that has a value of 1 for all points \(\{ P(x,y): x^2+y^2 \leq 1\}\) and 0 for all other points and \(N\) is the number of trials. Now it is well known that the precision of the approximation is proportional to \(1/\sqrt{N}\) and therefore more trials give better results. The problem in this case is that due to the looping nature of the LCPRNG, the sum in the nominator is simply \(m \times S_0\), where \(S_0 = \sum_{i=1}^{24700} \theta(P_i)\). For large \(N\) we have \(m \approx N/24700\) and therefore the approximation is stuck at the value of:

\begin{equation*} \tilde{\pi} = 4 \frac{\sum_{i=1}^{24700} \theta(P_i)}{24700}. \end{equation*}

It doesn’t matter if one samples 24700 points or if one samples 247000000 points. The result is going to be the same and the precision in the latter case is not going to be 100 times better but rather exactly the same as in the former case with 9999 times the computational resources used in the former case now effectively wasted.

Adding more threads could improve the precision if:

  • each thread has its own PRNG, i.e. the generator state is thread-private and not globally shared, and
  • the seed in each thread is chosen carefully so not to reproduce some other thread’s generator output.

It was already shown that there are at most 32 unique sets of points and therefore using only up to 32 threads makes sense with an expected 5,7-fold increase of the precision of the approximation (less than one decimal digit).

This leaves me scratching my head: was his docent grossly incompetent or did he deliberately gave him an exercise with such a bad PRNG so that he could learn how easily beautiful Monte Carlo methods are spoiled by bad pseudo-random generators?

It should be noted that having a cyclic PRNG is not necessarily a bad thing. Even if two different seed values result in the same unique sequence, they usually start the generator output at different positions in the sequence. And if the sample size is small relative to the cycle length (or respectively the cycle length is huge relative to the sample size), it would appear as if two independent sequences are being sampled. Not in this case though.

Some final words. Never use linear congruential PRNGs for Monte Carlo simulations! Ne-ver! Use something like Mersenne twister MT19937 instead. Also don’t try to reinvent RANDU with all its ill consequences to the simulation science. Thank you!


(Това вероятно е едно от най-добре поддържаните поизоставени местенца в световната мрежа. Редовно почиствано, архивирано, обновявано, проветрявано - като истински отглеждано е. — бел. авт.)

Не знам как ми дойде да пиша. Сигурно защото е петък, а петъците не са сред най-продуктивните дни, дори в държавата на усърдно работещите от 9:00 до 18:00. Днес е 22-ри ноември, което означава две неща.

Първо, от днес отваря Weihnachtsmarkt, или с други думи, изключително мазни Reibekuchen и Glühwein на корем.

Второ, 22-ри ноември е и денят, на който германската академична култура засвидетелства по вечерному своето уважение към германската ескапистка алкохолна култура, като в три от най-големите аудитории на RWTH (включително в аулата) прожектира Die Feuerzangenbowle. Носенето на термоси с домашно приготвено едноименно питие е задължително. Пиенето в синхрон със случките във филма - също. Всичко в името на онова усещане, че всички хора са приятели и принадлежат към нещо по-голямо от самите тях.

Сбогом, Twitter!

Всеки, който следи отблизо развитието на Twitter, знае, че 7 май 2013 г. е повратна дата във времевата линия на социалната мрежа. Това е датата, на която Twitter най-сетне ще изневери на идеала си да бъде платформата, която реализира идеята за социална мрежа по Правилния Начин™, представяйки за свободна и неограничена синдикация публичното съдържание (за разлика от оградените дворове (walled gardens) като Facebook и G+). Това е датата, на която Twitter официално ще пенсионира версия 1.0 на програмния си интерфейс, оставяйки като единствено достъпен програмен интерфейс версия 1.1. Въпреки очевидните предимства на последния, следната изключително важна функционалност няма да бъде налична повече:

  • неограничен и анонимен достъп до публичната информация — версия 1.1 изисква абсолютно всички извиквания към REST сървъра да бъдат автентицирани чрез OAuth, дори когато става дума за функции, свързани с достъпване на публична информация (в случая потоци, видими на сайта без необходимост от вписване с име и парола);
  • експорт в RSS — единственият формат на данните, поддържан във версия 1.1, е JSON.

В резултат имаме поредния ограден двор, като за мен специално става практически невъзможно лесното извличане на съдържание от Twitter, например за вграждане като интегрална част от ежедневния информационен поток, който следя през RSS. Отделното преглеждане на нещата от Twitter през сайта им, през десктоп клиент или през услуга на трети лица не е вариант, който бих приел.

Дълбоката ирония в случая е, че това се случва точно седмица след 20-годишнината от паметния ден, в който ръководството на CERN, под убеждението на сър Тим Бърнърс-Лий, подари безвъзмездно на човечеството технологията на World Wide Web с надеждата, че тя ще спомогне за развитието на един по-отворен и свързан свят, в основата на който стои свободната за достъп и обмяна информация.

Не мога да скрия, че Twitter беше любимата ми социална платформа, както и че това е втората ми раздяла с него. За съжаление, желанието за пълен контрол над достъпа до информацията от страна на компанията, вероятно като следствие от желанието всичко и всеки да бъде анализиран с рекламна цел, надделя. Така че тук е мястото, където общият ни път свършва. За щастие, цялото текстово съдържание на потока ми вече може да се извади под формата на архив. Защо не включват в него и графичното съдържание от съответната услуга на Twitter не е много ясно, но, ясно или не, ще трябва да свалям снимките си на ръка. Все още обмислям дали да го налея в специална архивна секция тук или да го изпратя в кутията за спомени, като за момента везните клонят повече към втория вариант.

Дали ще ми липсва Twitter? От една страна да, заради хора като действащия командир на МКС и хапливия хумор на саркастичния марсиански ровър. От друга страна, не мисля, че ще ми липсва фрагментираният информационен поток. Напоследък установявам, че съм загубил частично способността да се концентрирам върху дълги и понякога скучни текстове — способност, която всеки учен трябва да притежава и да развива до съвършенство. Частична вина за това имат и накъсаните информационни потоци, които непрекъснато се изливат от Twitter и подобните услуги за микроблогване. Така че, очаквам спирането на последните да се отрази положително на омекналия ми когнитивен мускул. И като цяло животът в Германия (или поне в Ахен) има една положителна страна, свързана с предпочитанието към общуване лице в лице на живо (на по халба бира, разбира се), към която неусетно привикнах, макар организацията на събитията да става предимно през Facebook, което до известна степен налага присъствието ми там. Факт е, обаче, че напоследък социалният ми живот започна наистина сериозно да пречи на виртуалния, така че се налагат известни консолидационни мерки спрямо последния, за да се запазят нещата управляеми (първи въпросните мерки отнесе вече покойният ми профил в G+). Да не говорим за постоянно нарастващото ми отвращение от всичкия душевно-социален ексхибиционизъм в социалната епоха, в който понякога импулсивно взимам участие и аз.

Има и още нещо, свързано с разочароващта и донякъде очаквана (не-)активност в експеримента с браузърите. Интернет просията вече не дава резултатите, които даваше едно време. Но повече за това — в следващото издание.

В заключение, перифраза на една песен от началото на прехода:

Последен твит,
сбогом любими!

О, да, и без малко да забравя — весел Великден!

Изследване: Виртуален суперкомпютър от браузъри – струва ли си?

(Нетърпеливите могат директно да прескочат до частта Ако пожелаете да участвате, след което да се върнат към скучните технически подробности)

Въпреки непрекъснатото поевтиняване на изчислителните ресурси, закупуването на голяма изчислителна машина все още е проблем пред редица недобре финансирани групи. Също така не всеки може да си позволи закупуването на изчислително време от доставчици на облачни услуги. Много преди времето на облаците, проектът SETI (Search for Extra-Terrestrial Intelligence) популяризира изчислителен модел, при който хиляди домашни потребители можеха да дарят неизползваното изчислително време на собствените си компютри за извършване на научни изследвания. SETI@home, както се наричаше първоначално проектът, стана един от най-мощните виртуални суперкомпютри в света. Идеята беше доразвита по-късно под формата на универсалната платформа BOINC, която позволява на всеки да създаде свой виртуален суперкомпютър, ако успее да убеди достатъчен брой потребители да инсталират платформения клиент и да се присъединят към проекта. Необходимостта от инсталиране на специален клиент донякъде се оказа пречка пред редица потребители с недостатъчни технически познания. От друга страна, сложната сървърна инфраструктура, необходима за работата на BOINC, се оказа пречка пред редица научни проекти.

В същото време сме свидели на постепенна промяна в парадигмата за компютър. Освен неспирното навлизане на таблетите, съществува реална опасност мощните персонални компютри да се превърнат в нетбуци на стероиди, прости платформи за изпълнение на уеб браузъри. За справка: Google Chromebook Pixel.

Съвременните браузъри на практика са малки виртуални машини, които, освен че могат да показват картинки и текст, позволяват изпълнение на изключително сложна логика, написана на JavaScript. По естествен път възниква въпроса, не може ли да се използва тази сила на браузърите за създаване на разпределени изчислителни системи, при които крайният клиент не трябва да инсталира нищо (zero setup distributed computing) – достатъчно е последният просто да посети определена страница в Интернет, за да дари изчислителните си ресурси.

Идеята не е моя. Още преди няколко години, когато беше първоначалният бум на BitCoin, някой се беше сетил да напише JavaScript код за копаене на BitCoin, след което редица хора се опитаха да се възползват от различни XSS атаки, за да превърнат браузърите на нищо неподозиращи хора в копачи. JavaScript обаче няма целочислени типове, а представя вътрешно всичко като числа с плаваща запетая. Съответно криптографските операции, необходими за копаенето на BitCoin, бяха изключително бавни в реализация на JavaScript. Не така стоят нещата с редица научни програми, които извършват предимно изчисления с плаваща запетая.

Това ме наведе на мисълта: колко точно по-бавен е JavaScript в сравнение с традиционните компилирани езици, използвани в научната и инженерна практика, като Fortran и C/C++? Така се роди идеята за това изследване, чиято цел е да отговори по наукообразен начин на поставения въпрос.


Съществуват десетки браузъри и операционни системи, върху които те се изпълняват. Отделно съществуват стотици видове “железа”, върху които пък се изпълнява стекът от браузъри и операционни системи. Това прави трудно да се даде еднозначен и директен отговор, още повече, че браузърните технологии непрекъснато се усъвършенстват. Също така едно сериозно изчисление изисква продължителна работа на скрипта, което не се харесва на много от браузърите.

Въпреки всички технически детайли, големият въпрос е: струва ли си? С други думи: какво количество изчислителни ресурси може да се очаква от един средностатистически потребител?


Всеки компютър има ограничен изчислителен капацитет. Използването на интерпретиран език като JavaScript допълнително редуцира полезната част от този капацитет. Фактът, че почти никой не държи пуснат браузър 24/7 – още повече. Така че разработих един тест с две лица: първото лице е т.нар. нативен тест, който представлява компилирана и оптимизирана програма, която измерва базата (в случая – граничните възможности) на “желязото” (хардуера); второто лице е реализация на същия алгоритъм, но на JavaScript, така че да може да се изпълнява в модерни браузъри. Тъй като и двете реализации правят едно и също, времето за изпълнение на всяка от тях може директно да бъде съпоставено и така да се оцени, какъв процент от наличните ресурси могат да се оползотворят през JavaScript.

JavaScript версията има възможност да работи в режим на непрекъснато повторение. Така може да се оцени влиянието на изпълнението на заден фон и на нормалната работа на потребителя върху скоростта на изпълнение на работните скриптове, както и обратното влияние.


По съществото си това е статистическо изследване. Подобни изследвания изискват множество участници, които малко или много покриват широк спектър от потребителски профили и компютърни конфигурации. Въпреки че съм тествал стотици пъти собствения си компютър по време на разработката на софтуера, това няма абсолютно никаква статистическа тежест. Затова призовавам всичките си познати и непознати да станат участници, пък било то дори за малко, в това изследване.

Какво се изисква от вас? Минимални усилия да изтеглите нативния клиент и да го стартирате, след което да регистрирате компютъра си и да започнете да изпълнявате браузърния тест, докато вършите нормалната си работа.

Какво печеля аз? Анонимна статистическа информация за относителната скорост, с която различни браузъри изпълняват научни алгоритми върху различни хардуерни конфигурации. Имам някои идеи за платформа (с отворен код, разбира се) за подобни приложения, но реализацията ще изисква значително количество човешки ресурси, така че събраната информация ще позволи евентуално да се спести прахосването на ресурсите (да се чете: свободното ми време, а по-късно и свободното време на други хора). Но най-важното е, че ще спечеля спокойствие нощем, защото идеята за това изследване се върти в главата ми от доста време насам и не ми дава покой :)

Какво печелите вие? Удовлетворение, че допринасяте за някаква мъгливо дефинирана научна и инженерна кауза. Но, ей, това все пак е наука. След време, също така, ще разберете кой браузър има най-добър JavaScript двигател, поне що се отнася до изпълнението на научни програми.

Ако пожелаете да участвате

Прекрасно! Предварително благодаря за което. Изследването се намира тук:

Смятам, че инструкциите там са достатъчно подробни, но, все пак, ето описание, стъпка по стъпка, какво е необходимо да направите.

Тъй като моделът за сигурност на JavaScript не му позволява да има достъп до ключови параметри на компютъра, на който се изпълнява браузърът, а също така с цел тестване на способностите на самото “желязо”, е необходимо първо да свалите от страницата на изследването нативен клиент за операционната система, с която работи вашия компютър. За момента такъв е наличен само за Windows, така че инструкциите по-долу са валидни за нея ОС. Нативният клиент се разпространява като ZIP архив за максимална преносимост и няма нужда от инсталиране, т.е. може да се използва и от потребители, които нямат администраторски права. Необходимо е единствено да разархивирате сваления файл и да стартирате HPCGUI.exe. Ако получите съобщение за грешка при стартиране или по време на изпълнение на HPCGUI, моля погледнете секцията Известни проблеми и разрешенията им за евентуално налично решение.


Главен прозорец на нативния клиент

Работата с програмата е изключително елементарна: необходимо е просто да натиснете Run simulation(s). Клиентът ще изтегли автоматично последната версия на пакета от тестове и що го стартира:


Работеща симулация

Когато тестът приключи, резултатът от него, форматиран като XML, ще се появи в голямото текстово поле. Необходимо е да пренесете това съдържание в полето за регистрация на страницата на изследването. Бутонът Copy output е поставен за удобство – след натискането му, резултатът ще бъде поставен в клипборда на Windows:


Резултатът в нативния клиент

Поставете копираното съдържание в текстовото поле във формата за регистрация на страницата на изследването и натиснете Submit:


Форма за регистрация в сайта

При успешно изпращане на резултатите, започва същинското изследване:


JavaScript тест в действие

Тестът може да работи в два режима: единичен и непрекъснат. Единичният режим, който е подразбиращият се в случая, е подходящ за тестване на върховната производителност на даден браузър. Непрекъснатият режим, който се активира при сложена отметка на Continuously, повтаря до безкрайност теста с кратки почивки от по 30 секунди между отделните изпълнения.

За целите на експеримента е необходимо или да пуснете многократно единичен тест, или да го оставите да работи известно време в непрекъснат режим. За предпочитане е да направите и двете, като единичният тест е хубаво да бъде пуснат няколко пъти в единствения таб на единствения прозорец на току що стартиран браузър, когато никое друго “тежко” приложение не използва ресурсите на компютъра. Това ще даде оценка на праговите възможности на JavaScript интерпретатора на вашия браузър.

Ядрото на изследването е непрекъснатият режим. Той е предназначен да изследва поведението на JavaScript интерпретатора на вашия браузър, когато даден скрипт се изпълнява непрекъснато на заден фон. Това е и режимът, който най-много ме интересува, тъй като в подобен режим би се изпълнявало едно типично разпределено браузърно приложение. Част от възможните сценарии са:

  • единствен прозорец с единствен таб, в който работи тестът, но прозорецът не е на преден план, примерно е минимизиран или друго приложение е на преден план;
  • единствен прозорец с няколко таба, като табът с теста не е на преден план;
  • няколко прозореца, като тестът се изпълнява в прозорец, който не е на преден план.

Колкото по-дълго време работи тестът и колкото повече нещата, които правите, докато той върви, се доближават до нормалната употреба на компютъра, толкова по-значим ще бъде приносът ви към изследването. Забележете, че тестът не може по никакъв начин да следи същината на вашата активност, като последната се отразява единствено под формата на различно забавяне в изпълнението на тестовия скрипт. Въпроси като колко точно време прекарвате в (а)социални мрежи и по сайтове за възрастни, както и каква музика и филми пиратствате, изобщо не попадат в кръга на интересите ми. Всъщност, шепата читатели тук са всички до един достатъчно технически грамотни и нямат нужда от подобни обяснения, но година и нещото престой в Германия вече дава някои отражения.

Добре би било, ако разполагате с няколко инсталирани браузъра, да пуснете теста във всеки един от тях. След като регистрирате компютъра си с един от браузърите, можете да използвате малката форма в горния край на страницата на изследването, където следва да впишете т.нар. идентификатор на тествания компютър (benchmark ID), който може да получите, натискайки бутона Copy benchmark ID на нативния клиент.

Въпроси и отговори

Какви тестове са включени в пакета?

Към настоящия момент пакетът включва единствен тест – молекулярна динамика на симулирана система от 1000 атома, които взаимодействат помежду си посредством потенциал на Lennard-Jones. Този потенциал в добро приближение описва взаимодействието между атоми на благородни газове като хелий (He), неон (Ne), аргон (Ar) и т.н. Също така потенциалът добре описва взаимодействието между атоми на благородни метали и въглеродни подложки, например при симулиране на процеса на изпарително покриване на въглеродни нанотръби със злато или платина за каталитични цели.

Защо резултатите от нативния клиент се различават от тези от теста в браузъра?

Поведението на системите от повече от две тела е хаотично – малките разлики в началните условия нарастват експоненциално с еволюцията на системата във времето. Също така, молекулярната динамика е метод за приближено решаване на уравненията на движение, а и компютрите работят с крайна точност на представянето на числата с плаваща запетая. По тази причина точната форма на траекториите и стойностите на различните величини на всяка стъпка нямат особен физичен смисъл, а само техните термодинамични средни стойности. Консултирайте се с произволен курс по термодинамика за по-задълбочено обяснение – ключовата дума е ергодична теорема.

Различната реализация на математическите операции в различните браузъри също може да доведе до разлика в показваните стойности. Докато Firefox, Safari и Internet Explorer дават идентични резултати, то тези от Chrome се различават от останалите. Това е напълно нормално.

Каква точно информация изпраща нативния клиент?

Нативният клиент използва програмата CHKCPU32.exe, включена в разпространявания архив. CHKCPU32 предоставя следната информация за техническите характеристики на процесора на вашия компютър:

  • модел и производител;
  • брой процесори, ядра и хардуерни нишки;
  • тактова честота;
  • поддържано множество инструкции;
  • размер на кеш паметта.

На практика нативният клиент изпраща изхода от изпълнението на командата CHKCPU32 /X. Примерен резултат от моя собствен компютър:

<?xml version="1.0" encoding="utf-8" ?>

  <ident>CPU Identification utility</ident>
  <version>v2.11 final</version>
  <copyright>(c) 1997-2013 Jan Steunebrink</copyright>
  <cpu_vendor>Intel </cpu_vendor>
  <cpu_model>Pentium Dual-Core G600/G800 series Q0-step</cpu_model>
  <cpu_name>Intel(R) Core(TM) i5-2557M CPU @ 1.70GHz</cpu_name>
  <l1>64 KB</l1>
  <l2>256 KB</l2>
  <l3>3072 KB</l3>

Тази информация се използва от сървъра, за да предостави на нативния клиент версия на пакета от тестове, която е максимално оптимизирана за конкретното “желязо”. Никъде в нея не се съдържа лична информация.

Какво точно е “идентификатор на тествания компютър” и доколко той съдържа лична информация?

Идентификаторът (benchmark ID) позволява да бъде отличен един тестов компютър от друг, както и да бъдат свързани резултатите от нативния клиент и браузърните тестове (моделът на сигурност на браузърите не позволява скриптовете да достъпват информация извън т.нар. “пясъчник”, така че директен обмен между нативния клиент и браузъра е невъзможен). Технически представлява MD5 трансформация на името на компютъра, “осолена” със серийния номер на системния том. Комбинацията от двете е достатъчно уникална, така че не се очакват колизии по време на изследването. MD5 е еднопосочна трансформация, т.е. практически невъзможно е, дори ако използвам (нелегално) всички ресурси на суперкомпютъра на работа, да възстановя нито името на компютъра ви, нито серийния номер на системния том от идентификатора.

На практика вашето участие в изследването е анонимно, освен ако не решите да споделите изрично кой стои зад даден идентификатор.

Кои браузъри и операционни системи се поддържат?

Всеки съвременен браузър следва да работи. Тествал съм с Firefox 19+, Chrome и IE 9 на Windows 7. IE 9 е значително по-бавен от останалите браузъри, особено в 64-битов режим, в който е пъти по-бавен от иначе бавния 32-битов IE 9. По данни от други хора, IE 10 на Windows 8 се държи много по-добре.

За момента се поддържа само Windows, тъй като нативните клиенти за другите системи са още в процес на разработка. По редица причини програмата е тествана само на Windows 7 x64 с инсталирано MS Visual Studio 2010. Напълно е възможно да се появят проблеми на по-ранни или по-късни операционни системи – ако това се случи, оставете коментар с описание на проблема. Участници с Windows XP, Windows Vista, Windows 8 или сървърна версия на Windows са добре дошли.

Известни проблеми и разрешенията им

Стартирането на HPCGUI.exe пропада с грешка за липсващ MSVCR100.dll или MSVCP100.dll

Необходимо е да свалите и инсталирате (последното изисква администраторски права):

Microsoft Visual C++ 2010 Redistributable Package x86

Двете динамични библиотеки са включени в архива, но е възможно да имат допълнителни зависимости. Работя за статичното им включване в изпълнимия файл.

Стартирането на симулацията от нативния клиент пропада с грешка:

Execution of command '\some\long\path\simpack_win_opt.exe \other\long\path' failed (error 193)

Вероятно пътят до папката с нативния клиент е твърде дълъг. Преместете папката на друго място така, че пътят до нея да е по-къс. Това изглежда е ограничение в използваната библиотека от инструменти, което ще се опитам да премахна по-нататък.

Заключителни бележки

Изследването е в ранна бета, затова и публикувам текста единствено на български език. Възможно е да има още много грешки в програмите. Възможно е и хостингът ми да не бъде особено доволен, ако това стане твърде популярно. Затова всякакви положителни и отрицателни отзиви и обратна връзка са добре дошли. Ако нещо не работи, както се очаква, или просто искате да изразите възхищението или възмущението си, пишете ми на research маймуна icaci точка info.