computo ergo sum

(Отново) За паралелното програмиране

Wed, 03 Jun 2020 13:18:00 +0200

Вместо увод

По-добре късно, отколкото още по-късно. Доста вода изтече и много неща се промениха, откакто за последно писах тук за HPC. Всъщност откакто за последно писах тук изобщо. Едно от непроменимите неща, обаче, остава тенденцията на прехода от монолитни процесори с едно свръх-бързо ядро към процесори с множество относително по-бавни ядра или такива с огромен брой много прости ядра (напр. GPU). Дори часовниците не остават незасегнати. Силен двигател на тази тенденция е и масовото навлизане на машинното самообучение.¹

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

Паралелни архитектури

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

Първият клас е този на системите със споделена памет, при които множество изчислителни елементи (ИЕ) имат едновременен достъп до общ блок памет, като блокът може да бъде или относително монолитен и да осигурява еднакво бърз достъп от всеки един ИЕ, известно като униформен достъп до паметта UMA (Uniform Memory Access), или на йерархични нива, при които някои области от паметта са по-близо до определени ИЕ и съответно осигуряват по-ниско време на достъп и по-висока пропускателна способност от други, по-далечни области, известно като неуниформен достъп до паметта NUMA (от Non-Uniform Memory Access). Класически пример за UMA от света на x86 са многопроцесорните системи с Front-Side Bus технология за връзка между процесорите и контролера на основната памет, т.е. всичко от времето преди AMD64 и Intel Nehalem, докато пример за NUMA са всички многопроцесорни системи, където всеки процесор има собствен контролер на паметта, което включва практически всяка съвременна многопроцесорна система.

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

Разделението между двата класа е предимно на ниво физическа реализация, тъй като на логическо ниво всеки един от тях прави възможно емулирането на другия. Например, процесите в съвременните операционни системи (ОС) оперират в собствено виртуално адресно пространство и обменят информация помежду си само чрез специални комуникационни механизми на ОС, въпреки че съществуват в рамките на един и същ блок физическа памет. И обратно, механизмът на виртуалната памет прави възможно автоматичното споделяне и мигриране на данни между физически отделни блокове памет, известно като (виртуална) разпределена споделена памет или (v)DSM (от (virtual) Distributed Shared Memory). Струва си да се отбележи, че дори многопроцесорните системи в наши дни са пример за хардуерна реализация на разпределена споделена памет, тъй като всеки един процесор автоматично препраща операциите за достъп до области памет, намиращи се извън собственото му физическо адресно пространство, към съответния процесор, където те се намират.

Бидейки ортогонални, двата класа могат да се комбинират, като това е по-скоро норма, отколкото изключение. Например, практически всеки изчислителен клъстер в наши дни се състои от множество дву- или четирипроцесорни изчислителни възли, свързани помежду си с високоскоростна мрежа с ниско закъснение. Всеки изчислителен възел е NUMA на глобално системно ниво, докато ядрата във всеки един процесор имат UMA достъп до споделения кеш от последно ниво и до блока памет на него процесор.

Важна характеристика на една паралелна архитектура е нейната възможност да се разраства като брой ИЕ или т.нар. мащабируемост. UMA е изключително ограничена в това отношение, главно поради експоненциалното нарастване на хардуерната сложност с броя на ИЕ, които имат достъп до паметта. NUMA на теория позволява неограничено йерархично разрастване, но на практика е ограничена от изискването за кешова кохерентност. По-голямата част от NUMA реализациите са кеш-кохерентни, т.нар. ccNUMA, което означава, че промените в локалния кеш на един ИЕ се разпространяват и автоматично отразяват в кешовете на другите ИЕ. Без подобен механизъм реализацията на NUMA би била много по-проста, но това би било за сметка на значително усложнен програмен модел. Системите с разпределена памет са принципно неограничени, тъй като обмяната на съобщения там е явна и може да се локализира в определени области, когато алгоритъмът е избран подходящо.

SIMD и VLIW

Предните два класа се отнасят за паралелни системи, състоящи се от множество ИЕ, като всеки ИЕ е малко или много завършено процесорно ядро с контролна логика, АЛУ, изпълнителни блокове, конвейри и прочие. Но паралелизмът може да е на много по-ниско (или по-фино) ниво, по-специално на ниво инструкция, като това е бил пътят за постигане на изключително висока производителност през 70-те години на миналия век. Практичният паралелизм на ниво инструкция бива най-общо два вида.

Първият вид е SIMD (Single Instruction Multiple Data), при който една инструкция действа едновременно върху вектор (няколко еднотипни единици) от данни. Дължината на вектора в различните архитектури варира от два до стотици елемента. Дългите веркторни операции са начинът, по който Cray-1 постига през 1975 г. космическата за тогава производителност от над 100 MFLOPS². Основен недостатък на подобни системи е тяхната тясна специализираност в обработка на големи масиви от еднотипни данни. Далеч по практични са късите векторни операции, с каквито е снабден практически всеки съвременен процесор, независимо от архитектурата му.

Вторият и значително по-рядко срещан вид е VLIW (Very Long Instruction Word), при който една инструцкия кодира множество различни операции, които се изпълняват едновременно от различни независими изпълнителни блокове в процесора. За разлика от SIMD, който е вид паралелизъм по данни, VLIW е паралелизъм по задачи (или операции). Типичен пример са повечето цифрови сигнали процесори (DSP) и по-ранните модели GPGPU на ATI. Вид VLIW е и EPIC архитектурата на Itanium.

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

Програмни модели

Всеки един от двата класа паралелни архитектури може да бъде разглеждан по много различни начини на програмно ниво, като обаче някои от тези начини са по-подходящи и естествени за съответния клас, а други – не толкова. Наличието на споделена памет позволява лесна обмяна на информация между отделните ИЕ под формата на споделени променливи. И не само това – архитектурата позволява споделяне и на изпълнимите инструкции, което силно опростява модела на зареждане и изпълнение на паралелните програми. Най-удобното в случая е, че съществува готов и широкоразпространен програмен модел, който съответства директно на архитектурата – този на многонишковите процеси, където нишката е абстракция на независимо изпълняващ се поток инструкции. Нишките могат да бъдат както отделни контексти в рамките на един последователен поток, между които се превключва с някакъв механизъм в потребителски режим, често наричани зелени нишки (green threads по името на първата Java библиотека за многонишково изпълнение) или фибри (fibers), така и олекотени процеси (или LWP от Light-Weight Processes), които споделят в рамките на един процес на ОС общо адресно пространство и системни обекти като дескриптори на отворени файлове и мрежови съединения, но се изпълняват независимо един от друг. Съществуват множество приложни програмни интерфейси (API) за създаване, контрол и синхронизация на двата вида нишки, като LWP са значително по-полезни в контекста на паралелното програмиране, тъй като могат да се изпълняват върху различни ИЕ.

Писането на многонишкови програми е като цяло трудоемко и най-вече силно платформенозависимо, поради което са разработени различни абстрактни модели, които да го облекчат. Един такъв модел е OpenMP, който ще бъде предмет на следващата статия от серията. OpenMP използва специални директиви на компилатора, реализирани под формата на прагми (C/C++) или коментари (Fortran), които модифицират поведението на съществуващите езикови конструкции. Това позволява не само създаването на нов паралелен софтуер, но и прагматичната постъпкова паралелизация на съществуващ последователен код. Версия 4.0 на OpenMP спецификацията добави и преносими SIMD конструкции, които да заместят различните за всеки един компилатор директиви за векторизация на кода.

Малко по-различен модел е този на Intel Threading Building Blocks (Intel TBB или просто TBB), което е библиотека от контейнерни класове и алгоритми за C++. За разлика от OpenMP, TBB не изисква специален компилатор и се поддържа на практически всяка платформа, за която съществува достатъчно съвременна реализация на C++.

Към класа на многонишковото програмиране спадат и платформите за изпълнение на операции с общо предназначение върху графичен хардуер (GPGPU от General-Purpose computing on Graphics Processing Units) като CUDA и OpenCL. OpenCL е интересен с това, че е отворен стандарт и поддържа не само различен вид графичен хардуер, но също така всякакъв вид хетерогенни изчислителни добавки, известни като ускорители (accelerators), включително и стандартни процесори и FPGA. Както CUDA, така и OpenCL, са платформи от сравнително ниско ниво, които оставят видими значително количество хардуерни детайли, поради което върху тях съществуват редица абстракции от по-високо ниво. Една такава е SYCL, продукт на организацията зад OpenCL, която е набор от класове и алгоритми на C++ и среда за изпълнение, която динамично превежда класовете и алгоритмите в OpenCL код. Друга абстракция и надстройка на SYCL е Data-Parallel C++ (или DPC++) – отроче на Intel, което те искрено се надяват да се наложи като новият отворен стандарт. Дали това ще се случи наистина, единствено времето ще покаже. SYCL и DPC++ са много по-близки до TBB като структура на програмите, отколкото до OpenMP.

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

Програмирането на архитектури със споделена памет е значително по-сложно, тъй като липсата на споделено адресно пространство води до необходимост от явен обмен на споделена информация между отделните ИЕ. Това най-често става под формата на съобщения, които представляват пакети от силно-, слабо- или напълно нетипизирана информация. Самото предаване може да бъде както функционалност на операционната система, така и функционалност на някакъв вид междинен софтуерен слой и/или среда за изпълнение (middleware). Като пример за първата може да се посочи приложният интерфейс на BSD сокетите, който направи възможно широкото приемане на TCP/IP и експлозията на мрежовите услугите и Internet. И както сокетите са де факто стандартният интерфейс за обмяна на неструктурирана информация върху множество различни мрежови протоколи в слабо свързани системи, така интерфейсът за предаване на съобщения MPI (Message Passing Interface) е де факто стандартът за предаване на структурирани съобщения в силно свързани системи, каквито са повечето изчислителни архитектури с разпределена памет. MPI стъпва върху множеството съществуващи транспортни механизми и скрива редица техни детайли, като предоставя на приложенията сравнително прост метод за адресация на съобщенията, както и готова реализация на някои често срещани и относително примитивни операции.

Практически примери

Идеята ми е да покажа в рамките на няколко последователни статии най-разпространените парадигми за паралелно програмиране, като във всяка една от тях да покажа на практика процесите на декомпозиция и реализация с използването на съответната парадигма. За целта ми трябват примери, които хем да бъдат достатъчно прости, за да не се загуби паралелизацията в шума на основния код, хем да имат някакво практическо значение. Затова и се спрях на следните три:

k-means клъстеризация – широкоизползван и достатъчно прост за реализация метод от машинното самообучение;
игра Живот на Конуей – любим пример за клетъчен автомат, също така почит към паметта на автора му, Джон Конуей, който наскоро стана нелепа жертва на COVID-19;
оцветяване на множеството на Манделброт – солидна основа за дискусия на особеностите при разпределяне на работата в паралелните системи, страничен продукт на чието решение са красиви визуализации на де факто символа на фракталната математика.

Както обясних по-рано, OpenMP представлява набор от директиви на компилатора, които позволяват постъпковата паралелизация на съществуващи последователни програми, поради което и ще започна серията именно с него, като едновременно с това ще представя всеки един от трите примера и тяхното класическо (последователно) решение. Като език ще използвам C++, защото той е най-големият общ делител на всички методи, които искам да разгледам, като ще се придържам към максимално C-подобно подмножество, т.е. нищо няма да бъде идиоматичен C++. За MPI ще дам и пример на Python, тъй като неофициалната реализация mpi4py продължава да набира популярност. Всички примери ще бъдат по възможност междуплатформени, с изключение на тези за “ръчното” многонишково програмиране, а където е възможно ще приведа и времето за изпълнение в различни конфигурации върху Intel i7-5820K под 64-битов Windows 10.

Често представяно като изкустен интелект, което няма особен смисъл отвъд маркетинга. ↩︎
милиони операции с плаваща запетая в секунда ↩︎

Реформа №2

Wed, 06 May 2020 13:05:20 +0200

Отново реформа. Този път реформа на реформата. След малко повече от пет години, icaci.info отново шава, показвайки, че слуховете за неговата смърт са някак преувеличени.

Всичко тече, всичко се променя, предпочитанията към статичните генератори на съдържание – също. Nikola е приятен за работа, но е архитектурно тежък и има множество проблеми, които в някакъв момент стават нещо повече от досада, затова и беше изместен от Hugo, който от години движи англоезичния ми сайт. Hugo е светкавично бърз, тъй като е написан на Go(lang) – no-bullshit език, към който напоследък развивам бързо афинитет, след разочарованието от посоката, в която вървят езици като C++. Предпочитаният маркъп този път е Markdown, така че отново се наложи да конвертирам, което нарочно направих на ръка, като в процеса отсях някои детинщини и пооправих правописно и стилистично други. Първоначално мислех да изтрия голяма част от съдържанието, но после реших, че това е, все пак, паметник, макар и частичен, на това кой съм бил и какво ме е интересувало през годините на присъствие в Интернет, затова и оставих нещата такива, каквито си бяха. Оказа се също, че съм дал редица обещания, които никога не съм спазил, къде поради липса на време, къде на мотивация. Факт е обаче, че ми липсва писането на родния език. В последно време се усещам, че мислите ми вече не текат така свободно, както преди време, вероятно поради жонглирането с три чужди езика и постоянното бомбардиране от социалните мрежи с фрагментирана информация, затова си обещах, че ще започна да пиша по-често тук. Като за начало, намерих няколко чернови на тема паралелно програмиране, които така и не съм довършил, така че това ще е основната ми цел. Да видим, какво ще стане този път.

Реформа

Fri, 03 Apr 2015 13:24:00 +0200

Реформите, особено бюрократичните, не са нещо, което се случва за една нощ. След има-няма 500 дена неактивност, icaci.info се реформира в напълно статична версия, генерирана с Nikola. Повечето стари URL-и са все още валидни и пренасочват към новите местоположения на писанията, но RSS-ът се мести на http://icaci.info/rss.xml. PixelPost галерията се трансфомира напълно в нещо не толкова красиво (все още), но концептуално малко по-различно.

Бидейки написан на Python, Nikola предпочита маркъп езика на Docutils – reStructuredText, макар голяма част от функционалността да може да се ползва и от Markdown. “Превеждането” от Textile (маркъп езика на Textpattern) в reStructuredText не беше особено тривиално, като Pandoc помогна много.

Основното предимство на Nikola, както и на повечето подобни генератори (или по-скоро компилатори) на статично съдържание, е, че цялото текстово съдържание идва от обикновени текстови файлове, които могат да се създават с произволен редактор и да се държат (заедно с всички останали принадлежащи файлове) в система за контрол на версиите, напр. Git. Няма web интерфейс за управление, няма нужда от бази данни и няма нито един сървърен скрипт, което влияее благотворно върху сигурността на сайта. Изходният код на всяка страница (с изключение на автоматично генерираните индекси) е достъпна посредством връзката Source в горния десен ъгъл на заглавната лента.

Сега остава и да започна да пиша отново.

22.11.2013

Fri, 22 Nov 2013 15:31:07 +0100

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

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

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

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

Сбогом, Twitter!

Sun, 05 May 2013 12:20:13 +0000

Всеки, който следи отблизо развитието на 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+). Да не говорим за постоянно нарастващото ми отвращение от всичкия душевно-социален ексхибиционизъм в социалната епоха, в който понякога импулсивно взимам участие и аз.

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

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

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

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

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

Sat, 20 Apr 2013 17:37:51 +0000

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

Въпреки непрекъснатото поевтиняване на изчислителните ресурси, закупуването на голяма изчислителна машина все още е проблем пред редица недобре финансирани групи. Също така не всеки може да си позволи закупуването на изчислително време от доставчици на облачни услуги. Много преди времето на облаците, проектът 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 двигател, поне що се отнася до изпълнението на научни програми.

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

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

http://research.hiliev.eu/jshpcstudy/

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

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

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

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

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

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

Тестът може да работи в два режима: единичен и непрекъснат. Единичният режим, който е подразбиращият се в случая, е подходящ за тестване на върховната производителност на даден браузър. Непрекъснатият режим, който се активира при сложена отметка на 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" ?>
<chkcpu32>
<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_speed>1700</cpu_speed><speed_unit>MHz</speed_unit>
<cpu_name>Intel(R) Core(TM) i5-2557M CPU @ 1.70GHz</cpu_name>
<cpuid_sign>0x0206A7</cpuid_sign>
<physical_cpus>1</physical_cpus>
<cores>2</cores>
<threads>4</threads>
<htt>0</htt><xd>1</xd><_64bit>1</_64bit><vt>0</vt>
<mmx>1</mmx><_3dnow>0</_3dnow><sse>1</sse><sse2>1</sse2><sse3>1</sse3>
<ssse3>1</ssse3><sse41>1</sse41><sse42>1</sse42><sse4a>0</sse4a>
<l1>64 KB</l1>
<l2>256 KB</l2>
<l3>3072 KB</l3>
</chkcpu32>

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

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

Идентификаторът (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.

Последната линейка на София

Sun, 10 Mar 2013 18:17:02 +0000

Разбрах съвсем случайно за него днес от WDR 3 (нещо като немски еквивалент на радио “Христо Ботев”), което от известно време непрекъснато върви на уредбата в хола. Тъжно е, че някой би употребил точно прилагателното последната, когато става дума за обществена услуга, чиято мисия е точно предотвратяването на преждевременното настъпване на последния момент в живота на човек. Още по-тъжно е, че това лице на страната ни, в частност на столицата, печели награди от френската културна и телевизионна общественост.

И няма как да не ти стане тъжно, когато някой по върховете смята, че проблемите се решават не с реформи, а с нов бранд [sic] и с ново лого на страната, и че 1,4 млн. лв. за това е нормална сума. Само където действителността е отчайващо грозна, и подобни филми, а сега и Google street view, го показват. И никакви рекламни трикове и скъпи картинки не могат да го замажат.

Не съм гледал Sofias letzte Ambulanz, но дори публично достъпните сцени на тресящата се през дупките по улицата линейка са достатъчно потресаващи. (прощавайте за повторението)

За щастието

Sat, 02 Mar 2013 00:05:37 +0000

Преди почти месец разузнаването докладва, че предишното писание е възможно да е предизвикало известен смут сред около 33% от четящите тук (което вероятно прави един или двама души), поради което започнах да списвам някои пояснения. След това ми се струпа работа и малко поотоложих, но след годишния Mitarbeitergeschpräch днес, където отново засегнахме темата за щастието, както професионалното, така и личното, седнах да завърша това писание.

Понякога в нещата които правя, и най-вече в тези, които пиша, прозира капка меланхолична тъга, която лесно може да се сбърка с нещастие или с някаква форма на депресия. Но истината е, че не съм нещастен и/или депресиран. Напротив, от известно време насам преоткривам личното щастие – онова, което идва отвътре. Бях позабравил този факт, но щастието всъщност е вътрешен процес, който обаче изисква известно волево усилие, за да се поддържа. Никой не може да ти даде отвън истинско щастие, ако дълбоко вътре в себе си ти не желаеш наистина да бъдеш щастлив, или дори и да може, това външно щастие е точно толкова трайно, колкото трайно е присъствието в живота ти на породилия го. Човек лесно бърка някои емоционални моменти с истинското щастие и често пада жертва на коварната грешка, допускайки външното щастие да измести вътрешното и така позволява на други да бъдат господари (съзнателни или не) на емоциите му. Още по-трагично е, когато двама души допуснат това един спрямо друг и така се породи самоподхранваща се циклична зависимост. Резултатът е, че ако връзката между двамата се прекъсне по една или друга причина, то остават за дълго две изключително нещастни и объркани човешки същества.

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

А меланхоличната тъга – тя е моя вечна спътница. Вероятно плод на лекото ми биполярно разстройство, тя ми помага да познавам радостта и щастието. Не бива да се забравя психофизичният закон на Вебер-Фехнер: човек е устроен така, че усеща не абсолютната стойност на външното влияние, а само относителната му промяна. Едно от следствията на това е хедонистичната адаптация¹ – човек лесно свиква с хубавото и удобното, в резултат на което последното постепенно губи статуса си на нещо специално и се превръща в нещо съвсем обикновено, резултат от промяната на положението на базовото ниво². Затова по мъничко тъга понякога (като “понякога” означава “не много често”, което пък със сигурност не означава “всеки ден”) е полезна, защото не позволява да бъде подложена на хедонистична адаптация радостта от живота, поради пресищане на допаминовите рецептори в мозъка.

И така, щастието се оказа въпрос на личен избор и сега съм щастлив в положението, в което сам се насадих. Щастлив съм и това създава верига на положителна обратна връзка – нещата, които върша напоследък, ме правят още по-щастлив, което започва да се отразява обратно във всички аспекти на живота ми, включително и в нещата, които върша напоследък. И още, превантивна забележка: идва ми отвътре, така че в Холандия ходя само и единствено на гости на много скъп приятел, а не за да търся специфичните за нея държава източници на щастие (намиг, намиг)

Импликацията в случая е възможно да има спекулативен характер (бел. авт.) ↩︎
Други следствия са съответно измерването на силата на чалга-и-поп шума от радиото в dB и на привидната яркост на звездите в логаритмичната скала на звездните величини (бел. авт.) ↩︎

Една година в Германия

Fri, 01 Feb 2013 21:24:48 +0000

Още помня всеки звук, всяко движение, всяка глътка въздух него ден – 23-ти януари 2012 г. – на пръв поглед обикновен, забързан по софийски, зимен понеделник. На пръв поглед обикновен маршрут по булевард Брюксел, почти пуст както обикновено, през входа на Терминал 2, където, както обикновено, цари суматоха от пристигащи и заминаващи, посрещачи и изпращачи, през проверката за сигурност и граничния контрол, до седалките в партера на изхода, от който автобусите извозват пътниците до спрелите някъде там самолети. Най-обикновен маршрут – бях го изминавал в двете посоки поне пет пъти за предишните няколко години. Но нещо този път беше различно. Защото всяка следваща стъпка ставаше все по-трудна – краката ми като че се наливаха с олово, а светът наоколо бавно се стапяше и превръщаше в сън. Какво правя? Защо на билета ми до DUS не фигурира обратен полет?! Нима е еднопосочен? Еднопосочен?! Къде отивам? Каква Германия?! Та аз дори не знам езика и едва преживях три дена в Nürnberg по-рано! Къде ще живея? Та аз една видеокасета не мога да наема, какво остава за жилище в друга държава… Защо си го причинявам? Защо ни го причинявам? Защо им го причинявам? …

Всяко начало е трудно. Още по-трудно е, когато наивно си въобразяваш, че всъщност не е никакво начало, а само временно отклонение от пътя, след което отклонение всичко ще се върне и ще си бъде както преди. Реалността, обаче – онова, което се случва, докато кроим съвсем други планове, – доста бързо се включва с надлежна демонстрация, че всичко това са по детски наивни бленувания, че времето и разстоянието променят безмилостно всичко и всеки, и че независимо колко се бориш, идва момент, когато отклонението никога повече не може да се върне при предишния път. Не защото се е отдалечило твърде много от него, а защото предишният път внезапно се е стопил и отклонението вече не е никакво отклонение, а новият път, по който следва да продължиш нататък. Отново сам…

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

Да, измина една година. Това е само началото.

Интервал

Thu, 04 Oct 2012 23:05:03 +0000

Отново на 20. Преди време открих, че на всеки две години мога да ставам на 20, стига да избера подходящата бройна система. Просто ей така, от разсеяност забравям да добавя скобките с числото на основата и отново съм млад, безгрижен и необременен с рутината и необходимостите на живота като редови член на обществото. Но днешното 20 е специално, защото бройната система този път е шестнадесетична. И защото 0x20, освен че е 2⁵ (а днес е 5-ти и 10 в двоична бройна система е 2), е и кодът на интервала във всички широко използвани компютърни азбуки, дори в недоразумението, известно като “7-битова GSM азбука”, с която се борих като прасе с тиква съвсем наскоро.

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

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

Затова нека новата година от моето летоброене бъде годината на така необходимата глътка въздух, на почивка от лутането в търсене на смисъла, целта, пътя и щастието, на по-малко говорене и повече слушане, на дълбока интроспекция и размисъл, на преосмисляне на миналото и осъзнаване на настоящето. Годината, в която да бъда единствено себе си и за себе си. Просто годината на нищо повече и на нищо по-малко от един обикновен интервал – интервал във времето и интервал в пространството.

Годината на моя интервал.

!dead

Tue, 14 Aug 2012 20:40:12 +0000

icaci.info из нот дед! Само, подобно на автора си, е застинал дълбоко в безвремието на философското осъзнаване на целта и смисъла на Промяната. Промяната, която никога не е лека и която често боли, вътре и вън от нас. Промяната, която руши установеното с много труд и любов, поради което се страхуваме от нея, отпъждаме я и се пазим, заключвайки се зад дебелите плътно непроницаеми стени на страха от нея. Липсата на Промяна е удобна, сигурна. Но какъв би бил смисълът без Промяна?

Immer vorwärts, Schritt um Schritt,
es geht kein Weg zurück.

Промяна. Скоро.

Лекция на OpenFest 2011

Sun, 30 Oct 2011 19:24:38 +0000

След минутката телевизионна слава в предаването на БНТ “Красива наука”, вече практически нищо не ме спира да говоря пред публика от непознати хора. Затова и най-после се преборих с предразсъдъците си и реших да се включа с лекция в тазгодишното издание на OpenFest. Под заглавието “Направи си сам суперкомпютър” се крие доста амбициозна цел, но времето от 45 минути едва ли ще позволи да я реализирам изцяло. Все пак, ако проявявате някакъв интерес към мащабната изчислителна техника, то заповядайте идната неделя от 17:15 в зала “София” на Интерпред.

Лекцията преди моята, тази на Пейо Попов за електронните пари, и Bitcoin в частност, също ще си струва да присъствате. Залата е същата, а началото е час по-рано – в 16:15.

Bitcoin - митове и легенди (част 2)

Thu, 07 Jul 2011 21:29:54 +0000

Забележка:
Математическите формули в този текст са изписани на LaTeX, за визуализация на който се използва MathJax. Ако вместо формули виждате нещо като $\Var[nonce] = \frac{1}{p^2}$, то MathJax не функционира по някаква причина, най-вероятно блокиран от NoScript.

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

Сравнение с експерименталните наблюдения

Разглеждаме следната извадка от публичната статистика на басейна deepbit.net, обхващаща няколко дена на постоянна трудност $D = 1379192$:

Период	Блокове	Дялове	Средно	Късмет
29.06	57	80389531	1410343	+2.3%
30.06	64	79751252	1246113	–9.6%
01.07	62	83054752	1339593	–2.9%
02.07	57	85609229	1501916	+8.9%
03.07	55	86255018	1568273	+13.7%
04.07	65	89260819	1373243	–0.4%
05.07	51	98434841	1930095	+39.9%
29.06–06.07	411	602755442	1466558	+6.3%

Късметът е дефиниран като относителното отклонение на средното за деня от математическото очакване. Отрицателните стойности означават късмет, а положителните – каръщина. Върху тези данни може да се приложи т.нар. Z-тест:

$$Z = \frac{mean - \mathrm{E}[shares]}{\sigma / \sqrt{N}}\,,$$

където $mean$ е средното за деня на броя дялове $N$, а $\sigma$ е теоретичното стандартно отклонение на геометричното разпределение. 95% от всички случаи на отклонение от математическото очакване следва да попадат в рамките на $|Z| \leq 1.96$.

Период	Блокове	СОСС¹	Късмет	Z-мярка
29.06	57	13.2%	+2.3%	0.171
30.06	64	12.5%	–9.6%	–0.772
01.07	62	12.7%	–2.9%	–0.226
02.07	57	13.2%	+8.9%	0.672
03.07	55	13.5%	+13.7%	1.017 (!)
04.07	65	12.4%	–0.4%	–0.035
05.07	51	14.0%	+39.9%	2.853 (!!)
29.06–06.07	411	4.9%	+6.3%	1.284 (!)

С (!) е маркирано попадение в горната част на 95% доверителен интервал ($1 < |Z| \leq 1.96$). Средната стойност за 05.07 лежи извън рамките на две стандартни отклонения, но попада в рамките на три стандартни отклонения ($|Z| \leq 3$), което вече покрива 99.74% от възможните случаи.

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

Съвпадението между теоретичното геометрично разпределение и експерименталното такова е видимо и на следната графика:

С черно е показана хистограмата на броя блокове като функция на броя дялове за откриването им, а със сините импулси – хистограма на геометричното разпределение. Съвпадението е повече от добро. Вертикалната пунктирана червена линия показва математическото очакване.

В предишната част беше показано, че верояността за срещане на каръшки блок (с повече от средното дялове), последван от два късметлийски блока (с по-малко от средното дялове) е 14.7%, а вероятността за срещане на трите блока в произволен ред е 44.1%. Изброяването на срещането на такъв тип блокове в информацията от deepbit показва, че от общо 409 тройки 58 удовлетворяват шаблона ULL, а 172 тройки удовлетворяват шаблона 1U + 2L, което дава експериментални вероятности:

$p_\textrm{exp}(ULL) = \frac{58}{409} = 14.2\%$ при теоретична стойност 14.7%;
$p_\textrm{exp}(1U + 2L) = \frac{172}{409} = 42.1\%$ при теоретична стойност 44.1%.

Аналогично, шаблонът ULLL се среща 39 пъти от общо 408 четворки блокове, а шаблонът 1U + 3L – 147 пъти, което дава експериментални вероятности:

$p_\textrm{exp}(ULLL) = \frac{39}{408} = 9.6\%$ при теоретична стойност 9.3%;
$p_\textrm{exp}(1U + 3L) = \frac{147}{408} = 36.0\%$ при теоретична стойност 37.2%.

Вижда се, че експерименталните стойности са доста близки до теоретичните.

По-строгата дефиниция на късметлийски (по-малко от 1/3 от математичното очакване брой дялове) и каръшки (повече от 3 пъти математичното очакване брой дялове) блокове понижава теоретичните вероятности до $p(ULL) = 0.4\%$, $p(1U + 2L) = 1.2\%$, $p(ULLL) = 0.11\%$ и $p(1U + 3L) = 0.45\%$. Броят на извадките е твърде малък за надежно наблюдаване на толкова редки събития, което се потвърждава от факта, че комбинацията ULL не се среща нито веднъж, докато комбинацията 1U + 2L се среща само един път. Последното показва колко неправилно е разглеждането на поредицата от блокове само и единствено след срещането на особено каръшки блок.

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

СОСС – стандартно отклонение на средната стойност ↩︎

Bitcoin - митове и легенди (част 1)

Sun, 03 Jul 2011 22:34:03 +0000

Забележка:
Математическите формули в този текст са изписани на LaTeX, за визуализация на който се използва MathJax. Ако вместо формули виждате нещо като $\Var[nonce] = \frac{1}{p^2}$, то MathJax не функционира по някаква причина, най-вероятно блокиран от NoScript.

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

Ще се опитам да анализирам някои от най-разпространените заблуди в общността на копачите на битмонети. Тъй като не разбирам от финанси, ще се концентрирам само върху техническите митове и легенди.

Малко предварителна информация

Блоковете в Bitcoin се “изкопават” в резултат на криптографски процес, свеждащ се до изчисляване на двоен SHA256 хеш на съдържанието на част от блока, докато стойността на хеша стане по-малка от т.нар. цел. Хеширането се прилага върху заглавната част на блока, включваща следните полета:

номер на версията – за момента фиксирана на 0x00000001;
хеш на предишния блок – двоен SHA256 хеш на заглавната част на последно открития блок;
корен на дървото на Merkle за транзакциите, съдържащи се в блока;
времеви маркер на блока – стандартен Unix времеви маркер в брой секунди от епохата (00:00:00 UTC на 01.01.1970 г.);
компактен вид на целта – указва трудността, при която е бил генериран блока;
т.нар. “nonce” – променлива част от заглавието на блока, която започва от 0x00000000 и се увеличава с единица докато стойността на хеша стане по-малка от целта; преносът при препълване се записва в специалната първа транзакция, което променя стойността на корена на дървото на Merkle.

Основна заблуда: блоковете имат предварително определен размер; има големи и малки блокове

Генерирането на блок в Bitcoin е като игра на рулетка. На всяка стъпка от операцията се генерира 256-битов хеш, който се сравнява с целта. Хеширащата операция е детерминистична, но хаотична – при един и същи вход винаги се получава един и същи резултатен хеш, но промяна дори на един бит от входа води до получаване на напълно различен резултатен хеш – полезни и всъщност силно желани свойства на хеш функцията. Ако всички полета в заглавната част на блока са фиксирани, то хеш със стойност по-малка от целта ще се постигне при точно определена най-малка стойност на nonce. Единственото наистина фиксирано поле е това на версията, а всички останали се променят при едни или други условия:

хеш на предишния блок – променя се тогава, когато някой друг открие нов блок; нямаме контрол върху този процес, тъй като не контролираме изчислителните ресурси на останалите участници в мрежата (случаен процес);
корен на дървото на Merkle – променя се, когато има нова Bitcoin транзакция, която желаем да обработим и включим в съдържанието на блока или всеки път когато полето nonce прехвърли $2^{32}-1$; бихме могли да ограничим случайната промяна на полето, ако не приемаме нови транзакции (случаен процес);
времеви маркер на блока – променя се на добре известни периоди от време, като Bitcoin допуска до 2 часа отклонение от средното време на мрежата, така че стойността може да се държи фиксирана в известен период от време;
компактен вид на целта – променя се относително рядко – вендъж на всеки 2016 блока, като точният момент зависи от това кога ще бъде открит 2016-тия блок (случен процес).

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

Изводът до момента е: блоковете биха имали фиксирана отнапред големина, измерена като брой хеширания до откриване на печелившата стойност на nonce, но само ако в мрежата има един единствен участник, което очевидно не е така.

Втора основна заблуда: късметлии и каръци

Ще започна с малко елементарна теория на вероятностите.

На всяка стойност на $nonce$ съответства хеш в интервала $0 \ldots 2^{256}–1$, като вероятността той да е по-малък от търсената цел $target$ е:

$$ p(hash < target) = \frac{target}{2^{256}}\,. $$

Целта $target$ е функция на трудността $D$:

$$ target = \frac{\mathrm{0xffff} \cdot 2^{208}}{D} $$

или

$$ p(hash < target) = \frac{\mathrm{0xffff}}{D \cdot 2^{48}} = \frac{2.328271 \times 10^{–10}}{D} $$

(за простота нататък ще пиша само $p$)

Тъй като стойностите на хеша за съседни стойности на $nonce$ се отличават силно, то отделните събития “хешът с дадена стойност на $nonce$ е по-малък от $target$” са на практика независими. Тогава вероятността да бъде открита печелившата стойност на $nonce$ след $k$ на брой хеширания (т.е. $nonce$ да бъде равен на $k-1$) е:

$$ p(nonce = k-1) = (1 - p)^{k-1} p\,. $$

За случайните величини с подобно поведение казваме, че следват геометрично разпределение с параметър $p$. За това рапределение е известно, че математическото очакване, т.е. средната стойност от безброй много опити, е:

$$ \newcommand{\E}{\mathrm{E}} \E[nonce] = \frac{1}{p} - 1 = D \cdot 4295032833 - 1 \approx D \cdot 4295032833\,. $$

На практика обаче не можем да осредним безкраен брой опити, тъй като сме ограничени от крайното време, с което разполагаме, или в рамките на което правим наблюденията. Степента на отклонение на отделните измервания от средната стойност се нарича вариация на разпределението и за геометричното разпределение тя е:

$$ \newcommand{\Var}{\mathrm{Var}} \Var[nonce] = \frac{1 - p}{p^2} \approx \frac{1}{p^2} = D^2 \cdot 1.844731 \times 10^{19}\,. $$

Вариацията на геометричното разпределение е обратнопропорционална на вероятността за успех и в конкретния случай нараства с квадрата на трудността. Осредняването върху броя хеширания за откриване на $N$ (краен брой) блока дава средна стойност, която принципно се отличава от теоретичната, като нейната вариация е:

$$ \Var[mean] = \frac{1}{N} \Var[nonce] = \frac{D^2}{N} \cdot 1.844731 \times 10^{19}\,. $$

Средноквадратичното (стандартно) отклонение е квадратен корен от вариацията и тогава относителното средноквадратично отклонение на средната стойност на големините на $N$ блока при трудност $D$ е:

$$ \sigma(N) = \frac{\sqrt{\Var[mean]}}{\E[nonce]} = \frac{N^{-1/2}\frac{1}{p}}{\frac{1}{p}-1} \approx \frac{1}{\sqrt{N}}\,. $$

Важният извод от това е, че при един и същ брой блокове $N$, върху които осредняваме, отклонението от средната стойност е толкова по-голямо, колкото по-голяма е стойността на трудността $D$, но относителното отклонение зависи единствено от броя на блоковете, върху които се извършва осредняването. По централната гранична теорема самата средна стойност има разпределение, клонящо към нормално, центрирано в математическото очакване $\E[nonce]$, т.е. в дългосрочен план всички късметлийски периоди, в които средният брой хеширания е по-малък от математическото очакване, точно се компенсират от каръшки периоди, в които средният брой хеширания е по-голям от математическото очакване.

Голяма част от копачите групират усилията си в басейни (mining pools). Басейните работят като раздават дялове – блокове с най-ниската възможна трудност $D^1 = 1$. Когато клиентът реши и върне на басейна такъв блок (дял), вероятността той да удовлетворява по-строгия критерий на текущата трудност е:

$$ p(\text{share wins}) = \frac{D^1}{D} = \frac{1}{D} $$

Т.е. броят на върнатите дялове до решаване на блока е също геометрично разпределена велична с параметър $p = \frac{1}{D}$, като всичко написано за броя хеширания по-горе се пренася директно върху броя на дяловете за блок. Теоретичната средна стойност и вариацията на броя дялове до решаване на блок е равна на текущата трудност:

$$ \E[shares] = \frac{1}{p(\text{share wins})} = D $$ $$ \Var(shares) = D^2 - D \approx D^2\,(\text{за големи } D)\,. $$

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

Традиционно в копаческите Bitcoin общности се обръща специално внимание на броя дялове до решаване на блок (всичко по-надолу дословно важи и за $nonce$) в следните времеви интервали:

интервал на една и съща трудност – $N = 2016$ и относителното стандартно отклонение на средната стойност от теоретичното средно е ±2.2%;
интервал на една и съща трудност в рамките на един голям басейн (1/3 от общата изчислителна мощност) – $N \approx 672$ и относителното стандартно отклонение на средната стойност от теоретичното средно е ±3.9%;
един ден – $N \approx 144$ (средно по 2 седмици за 2016 блока) и относителното стандартно отклонение на средната стойност от теоретичното средно е ±8.3%;
един ден в рамките на голям миньорски басейн – $N \approx 48$ (1/3 от общата изчислителна мощност на мрежата) и относителното стандартно отклонение на средната стойност от теоретичното средно е ±14.4%;
няколко поредни блока – $N < 4$ и относителното стандартно отклонение на средната стойност от теоретичното средно надвишава ±50%.

Много важна особеност на геометричното разпределение е неговата силна асиметрия спрямо средната стойност. Стойностите на броя дялове и на $nonce$ са ограничени отдолу (1 за дяловете и 0 за $nonce$), но не са ограничени отгоре, т.е. съществува, макар и клоняща към нула, вероятност печеливш хеш да не бъде открит дори след многократно надвишаващи средния брой хеширания. От друга страна, вероятността намалява монотонно с увеличаване на $nonce$ и (парадоксално) е най-голяма при $nonce$ = 0, т.е. по-вероятно е да се открие печеливш хеш още от първия опит, отколкото след точно хиляда поредни опита! Ако се постави условието обаче печеливш хеш да бъде намерен за не повече от $N$ опита, то тогава говорим за монотонно растящата кумулативната функция на разпределение (CDF). 63% от блоковете се откриват след по-малко от теоретичния среден брой дялове, а останалите 37% след повече от теоретичния среден брой. И тук именно се корени генезисът на мита за късметлиите и каръците: 2/3 от блоковете се откриват след по-малко от средния брой хеширания, но тези над средното, макар и по-рядко срещани, се откриват след (често) на порядъци по-голям брой хеширания поради силната асиметрия на разпределението. Клопката, в която мнозина попадат, е че след като текущото търсене надвиши определен брой хеширания, блокът се обявява за много “голям” и се търси нов копачески пул, в който блоковете са “малки”. Къде е основата на заблудата?

След “голям” блок се чакат “малки” блокове

Вероятността блок да бъде решен след пресмятане на по-малко от средния брой дялове (или хеширания) е $p(Luck) = 63.2\%$. Вероятността да бъдат необходими повече от средния брой дялове е $p(Unluck) = 1 - p(Luck) = 36.8\%$ (разпределението на късметлийските и каръшки блокове следва отрицателното биномно разпределение, бидейки сума от множество геометрични разпределения). Вероятността да бъде наблюдаван каръшки блок (U), следван от два късметлийски (L), при това точно в този ред, е:

$$ p(ULL) = p(U) \cdot p(L) \cdot p(L) = 14.7\%\,. $$

Вероятността трите блока да бъдат наблюдавани в произволен ред е:

$$ p(1U + 2L) = p(ULL) + p(LUL) + p(LLU) = 44.1\%\,. $$

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

в точно тази наредба – $p(ULLL) = 9.3\%$;
в произволен ред – $p(1U + 3L) = 37.2\%$.

Ако се ограничим само в наблюденията на случващото се след появата на каръшкия блок, то не бихме забелязали 1/3 от случаите на късмет.

Вероятността намалява силно, ако се засилят дефинициите на късметлийски и каръшки блокове. Нека например за късметлийски да приемем блок, който се решава след по-малко от 1/3 от средния брой дялове (или хеширания). Вероятността за такъв късметлийски блок е $p(L) = 28.3\%$. Вероятността да бъдат необходими 3 пъти повече от средния брой дялове за решаване на каръшки блок е $p(U) = 5.0\%$. Вероятността да бъде наблюдавана комбинацията от един каръшки и два късметлийски блока, при това точно в този ред, е:

$$ p(ULL) = p(U) \cdot p(L) \cdot p(L) = 0.4\%\,. $$

Вероятността трите блока да бъдат наблюдавани в какъвто и да било ред на случване е 1.2%. Изискването да се наблюдава още един късметлийски блок понижава вероятността до $p(ULLL) = 0.11\%$ и $p(1U + 3L) = 0.45\%$.

Вероятността след каръшки блок да се наблюдава късметлийски по формулата за условната вероятност е:

$$ p(L|U) = \frac{p(LU)}{p(U)} = \frac{p(L) \cdot p(U)}{p(U)} = p(L)\,. $$

Резултатът е напълно очакван предвид статистическата независимост на случването на късметлийски и каръшки блокове. Късметлийските блокове се случват с една и съща вероятност независимо от типа на предхождащия блок. Същото важи и за каръшките блокове.

Смяна на басейна за избягване от “лош късмет”

Важно е да се разбере следният изключително важен факт: случването на блок с определен брой дялове по никакъв начин не влияе на разпределението на късмета в следващите блокове. Също така, откриването на блокове в различните басейни е напълно независимо, поради което можем да приложим разсъжденията от предишната точка директно върху случая на прескачане от басейн на басейн в търсене на късмета, който да компенсира вече случил се каръшки блок.

Копаенето в един басейн е също толкова резултатно, колкото и местенето в нов басейн след всеки новооткрит блок. Разликата между различните басейни е само във вариацията:

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

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

В част 2 ще покажа с числени експерименти съвпадението на теорията със случващото се в Bitcoin системата.

Краят на една епоха

Fri, 06 May 2011 20:16:41 +0000

Епохалните събития в родината ни обикновено са белязани с разрушения.

Обитателите на университетския комплекс в Лозенец вероятно разпознават сградата на снимката, превърнала се в своеобразен паметник на безвремието, в което изпадна Алма Матер с настъпването на Новото време. Скелетът на никога недостроената сграда на Центъра по информатика подлежи на демонтаж, който вече започна, както се вижда.

Скоро време ветераните във факултета ще се познават по това, че са виждали металното чудовище:

Когато бях на твоите години, тук беше металният скелет на една голяма и недостроена сграда…

Наука с Physon (2011)

Sat, 16 Apr 2011 21:35:56 +0000

Днес беше второто официално представяне на клъстера ни като част от Деня на отворените врати на Физически факултет на СУ. Решихме да се изхитрим и да минем мързеливо като само обновим числата по слайдовете от предишното. Кой да се сети, че дните на отворените врати традиционно се посещават и от ученици…

Трябваше да се импровизира, а лекцията се разтегли до над час, в това число и двете демонстрации, в които електронната ни дъска получи бойното си кръщене.

Следва статичната версия на представянето, за който проявява интерес:

Наука с Physon (Ден на отворените врати 2011) (PDF)

Отново с благодарности към финансиращите организации НФНИ и ЕК.

Обратно на линия

Mon, 11 Apr 2011 15:46:23 +0000

Той изсъхна след наводнението и отново е на линия. Той е по-шумен отвсякога сега, когато се наложи да премахнем издулия се и изгнил паркет и балатума и да го оставим върху мозайката. Той ще бучи на живо в събота, 16 април 2011 г., когато в Деня на отворените врати на ФзФ ще бъде представен (за пореден път) от 13:00 в семинар В44.

Ако си падате по бучащи компютри, пращящи лазери и плазми, цвърчаща електроника или се чудите как трошат парите на данъкоплатците ония във ФзФ на СУ, то заповядайте в събота и бъдете просветени (или възмутени) :)

Лайняната работа

Wed, 06 Apr 2011 13:17:41 +0000

Че администрирането на ИТ инфраструктура понякога е лайняна работа ми е добре известно отдавна, но никога не съм и подозирал, че изразът може да добие толкова буквално изражение…

Кратката версия

Клъстерът ни е разглобен и складиран, а стаята, в която се помещава обикновено, смърди на кенеф и изгнил паркет.

Дългата версия

Мивката върна вода от мръсния канал и помещението се наводни. До тук два пъти. Оказа се запушване в мръсния канал на по-долния етаж, където на мястото на мивката е включен ~~циркулационна помпа на водното на охлаждане на специална апаратура~~ водният кръг на охлаждането на дифузионна вакуумпомпа. Когато инсталацията работи през деня, ~~помпата набива вода в канала~~ водата от чешмата минава през кожуха на помпата и се набива в канализацията с налягането на водната инсталация, не може да се отича и се вдига по горните етажи. Първо се наводни стаята с инсталацията и обитателите ѝ запушиха отвора около маркуча за оточната вода с парцали. След това се наводни стаята под клъстерното и обитателите ѝ запушиха тамошната мивка с парцали и епоксидна смола. След това дойде ред на нашата мивка, която преля. Наложи се да я попиват с голи ръце и парцали. Климатиците поработиха доста усърдно за да изсушат стаята, а паркетът ще се маха. Тъкмо стаята изсъхна и днес мивката отново върна и преля. Този път на мен се падна да изгребвам от мивката и да попивам с парцали от пода лайняната вода. Добре, че намерихме първоизточника и го принудихме да изключи апаратурата и помпата, с което предотвратихме нови наводнедния… за днес.

Крайният резултат – две наводнени стаи и една сериозно овлажнена. Три компютърни лаборатории, които не работят. Една неработеща плазмена установка.

Може би някой ще попита какво прави мивка в стая със скъпа компютърна техника? Или защо собствениците на помпата са я включили, след като са имали подозрение, че отходният канал е запушен, понеже от него капе вода, без да проверят наличието на мивки в стаите на горните етажи? Добри въпроси, на които мога да отговоря прозаичо:

СУ. ФзФ на СУ.

Another job well done!

Sat, 26 Mar 2011 19:25:34 +0000

Днес е паметен ден за историята на високопроизводителната изчислителна техника в Софийски Университет. 20 дена преди да се навърши една година от началото на последното разширение на клъстера physon, следвано от поредица от технически премеждия с електрозахранването и охлаждането, днес процесът официално завърши. След два големи ремонта – прекарване на нова трифазна инсталация направо от главното табло на сградата и монтаж на втори климатик (огромно таванно прасе на General), нещата като че ли най-накрая си дойдоха на мястото и машината заработи с пълна пара така, както си я представяхме. При пълно натоварване на големия дял на машината, температурата в стаята остава стабилна, а двата UPS-а поддържат температури на батериите си от 25 и 20 градуса съответно, което е с 10 градуса по-ниско от времето, когато клъстерът вървеше на 60% от проектната си мощност.

И както казва Bender:

Another job well done!

Партито се отлага за след няколко седмици, когато е рожденният ден на машината :)

Кофите на бъдещето

Wed, 02 Mar 2011 21:17:08 +0000

500 години напред в бъдещето кофите за боклук работят под Windows XP:

Магнитните топчета

Fri, 25 Feb 2011 21:43:42 +0000

Днес ManiaX си празнува рождения ден. Покрай всички неща му подариха и комплект магнитни топчета (216 на брой) и кубче на Рубик от 4-ти порядък. Беше като на ИББ, но по-шумно, а стана и задушно (кога дискриминацията ще победи и всички заведения ще станат за непушачи?). Имаше много хора, може и да е имало познати сред тях… Топчетата обаче бяха МНОГО ЯКИ! Някой да иска да ми подари такива? :)

PocketBook 301+ с/у Kindle 3

Sat, 05 Feb 2011 21:39:17 +0000

По стечение на обстоятелствата ми попадна един Kindle 3 WiFi. Както е известно, това е едно от двете 6” устройства с екран по технологията Pearl (другото е Sony PRS650). Имах два електронни четеца, статив, DSLR фотоапарат. Остана ми само да запретна ръкави и да започна да ги снимам. Резултатите – след прекъсването.

(ако не ти се чете всичкото, цъкай tl;dr)

Следват снимките от сравнението на PocketBook 301+ и Kindle 3. Описанието на всяка една е в заглавието, което излиза при задържане на курсора върху нея.

Спецификация на устройствата

PocketBook 301+:

6” екран Vizplex, 800x600, 166 ppi, 4 нива на сивото за текст, 16 нива на сивото за картинки, контраст 6:1 (на места го дават с 16 нива на сивото и за текст, но производителят, доста неконсистентно при това, твърди ту 4/16, ту 16/16 – иди разбери)
CPU Samsung S3C2440AL-40 (400 MHz, ARM-9)
1000 mAh Li-Pol батерия
тегло 174 гр.

Kindle 3:

6” екран Pearl, 800x600, 167 ppi, 16 нива на сивото за текст и картинки, контраст 10:1
CPU Freescale i.MX353 (532 MHz, ARM-11)
1530 mAh Li-Pol батерия
тегло 241 гр.

Снимките

На първо място, двете устройства едно до друго в общ план за сравнение. Вляво е PocketBook 301+, а вдясно – Kindle 3.

(епиграфът на иврит е картинка, така че не гарантирам, че и двете разбират текстове на нея азбука)

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

Както се вижда, и двата четеца имат приблизително еднакви размери, като екранът на Kindle 3 е малко по-високо разположен. PocketBook 301+ няма бутони за разлистване на страниците отстрани, поради което най-удобната за използване поза е в хоризонтално положение с джойстик в горния десен ъгъл (понеже съм десняк). На тези снимки шрифтът на PB301 има кегел 20 pt, но на всички следващи съм го увеличил до 21 pt, уж за да прилича повече на този на Kindle, но сега, когато гледам снимките повторно, май съм сбъркал в преценката…

Снимка отблизо. Отново PocketBook е вляво, а Kindle – вдясно.

Шрифтът на PocketBook е свободният Gentium Plus, кегел 21 pt. Избран е механизъм за растеризиране на шрифтовете Embolden. На Kindle шрифтът е третият по големина, Typeface - regular. При това положение шрифтът на Kindle е видимо по-плътен. Имам и шрифт Droid Serif на PB, но малко ме примързя да го сложа – ще го направя през почивните дни. Черното на Kindle е определено по-черно – не може да се отрече, че технологията в Pearl е поне една идея по-добра тази във Vizplex.

Индивидуални “макро” снимки. Или поне най-макрото, което можах да постигна с наличното оборудване.

PocketBook 301+

Kindle 3

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

Kindle е несравнимо по-пъргав в отварянето и разлистването на книгите. FBReader на PocketBook работи със страници, не с положения, и при всяко отваряне на книга започва да ги изброява, което му отнема известно време, през което време обаче страниците могат да се прелистват. Промяната на кегела на шрифта или ориентацията на текста причиняват ново преброяване на страниците.

Междувременно, в Интернет се били намирали пакети с шрифтовете на Kindle (благодарение на suren от форума на HardwareBG), така че сравненията на дневна светлина продължават с уеднаквени шрифтове.

Дифузно дневно осветление

Растеризатор

Шрифтът изглежда по различен начин на двете устройства. И тъй като двата екрана имат една и съща плътност на пикселите и една и съща разделителна способност, то разликата явно се корени в настройките за растеризация на TrueType шрифтове.

Успях да докарам горе-долу един и същи текст на почти една и съща позиция за по-лесно сравнение:

100% изрезки на думата “light”:

Растеризаторът на PocketBook видимо добавя повече сиви пиксели и излишно влошава контраста. Хубавото е, че платформеното SDK е достъпно и потребителите от MobileRead форумите са направили нови версии на FBReader180, компилирани с по-нова FreeType (2.4), с които обаче ще си поиграя някой друг път.

В резюме

Очевидно Pearl е доста по-добра технология от Vizplex по отношение на постигания контраст на електронното мастило. И двата екрана са еднакво матирани и лъщят еднакво на ярко осветление, но черното на Kindle 3 изглежда по-тъмно. Изборът на шрифт и механизмът на неговото растеризиране също са изключително важен фактор за четимостта. Очевидно е, че Amazon са се постарали много в този аспект, докато PocketBook са оставили на потребителите си свободата да настройват всеки отделен елемент. Наличието на SDK и възможността за подобряване или пълна подмяна на основни приложения в украинското устройство също е голям плюс.

Post factum

Разбира се, след като всички снимки отдавна бяха направени, а постановката – развалена, се оказва, че Caecilia LT всъщност има и кондензиран вариант, който изглежда малко по-така на PocketBook-а…

tl;dr

Ако не те влече да програмираш и да настройваш, то взимай Kindle 3 – хем по-евтин, хем по-контрастен и с по-хубав шрифт, пък и има по-яки картинки :) После сваляй calibre и конвертирай на воля.

Доктори, доктори...

Thu, 03 Feb 2011 22:14:06 +0000

Понеже не спират да ме питат едно и също, а и често след това забравят и ме питат отново, смятам, че трябва да внеса известно пояснение по отношение на научните степени и званията в България.

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

След като човек се е изучил достатъчно и е решил, че науката е неговото поприще, той може да започне да придобива научни степени, които отразяват личните приноси на лицето в развитието на съответната научна област. Съгласно действащите закони научните степени също са две: доктор и доктор на науките. Степента доктор е първата научна, но в същото време и образователна степен, тъй като в хода на придобиването ѝ се получава и допълнително специализиращо образование. В дипломата за докторска степен е записано, че на лицето се присъжда образователната и научна степен “доктор” по определена научна специалност от класификатора на научните специалности в страната (в моя случай това е 01.03.19 “Физика на атомите и молекулите”). В англоезичните страни степента се нарича Philosophiae Doctor или PhD. Придобиването на научна степен доктор позволява на човек да постави пред името си “д-р” (на български) и “Dr” (на английски) или след името си “PhD” (на английски). Научната специалност обикновено не се включва и се казва само “доктор”, а не “доктор по физика на атомите и молекулите”. Когато това е необходимо, се добавя шифърът на специалността, напр. “доктор по 01.03.19”, което се използва за бърза оценка на пригодността на дадено лице да участва в комисия или съвет. Съгласно стария закон (вж. речника в края) за научните степени и звания, степента доктор се придобиваше след защита на дисертационен труд пред специализиран научен съвет на ВАК (Висша Атестационна Комисия) – орган на Министерски съвет, пряко подчинен на министър-председателя на Р. България. Същата издаваше дипломите за доктор, доктор на науките, доцент, професор и старши научни сътрудници, т.е. дипломата от ВАК за доктор има общодържавен характер и не е обвързана с конкретното висше учебно заведение или институт на БАН, където е придобита (името на последното дори не фигурира в документа).

Научната степен доктор не бива да се бърка с професионалната (най-често медицинска) степен доктор. Втората се придобива след защита на професионален докторат при много по-различни условия от тези, необходими за защита на научен докторат. Преди години научната степен доктор се наричаше кандидат на науките и подобно объркване не възникваше. В тях времена аз щях да бъда “кандидат на физичните науки” или “к.фз.н.”.

Следващата и най-висока научна степен, а именно доктор на науките, се придобива за особени заслуги в развитието на конкретна научна специалност, многократно надхвърлящи по обем и качество работата за придобиване на степента доктор. Степента се изписва с включване на конкретната научна област (сбор от научни специалности), в която е придобита, например “доктор на физическите науки” и се съкращава като “д.фз.н.” (за да не се бърка с доктор на философските науки), възможно е и без точки. Самата степен надгражда по-ниската доктор и втората не се изписва, т.е. няма “д.фз.н. д-р”, освен ако доктор в случая не обозначава професионален докторат (примерно медицински доктор, защитил и научна степен доктор на медицинските науки). В англоезичните страни съществува степен DSc, която обаче в Америка има съвсем различен смисъл, поради което някои доктори на науките предпочитат да използват “Dr. habil”, означаваща хабилитиран доктор. По стария закон степента се придобиваше след защита пред специализиран научен съвет на ВАК и получаване на държавна диплома от същата комисия.

Придобиването на дадена научна степен не показва положението на човек в научната йерархия. Последното става с т.нар. научни звания (по смисъла на стария закон):

в университетите: асистент, доцент, професор
в БАН: научен сътрудник, ст.н.с. II степен, ст.н.с. I степен

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

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

Промени в новия закон

Законът за развитието на академичния състав в Р. България (ЗРАСРБ) замени стария Закон за научните степни и научните звания (ЗНСНЗ) през 2010 г. С него беше прекратено съществуването на ВАК, а задълженията ѝ по присъждане на научни степени и научни звания бяха прехвърлени на университетите и БАН. При това положение новите дипломи се издават от съответните научни учреждения след защита пред комисия, съставена от членове на учреждението и външни такива, което доближава България до англо-американския модел, при който дипломата за PhD от реномиран университет тежи много повече от аналогична диплома от слабоизвестен университет. По силата на стария закон всички кандидати, независмо от университета или института на БАН, където са се подготвяли, защитаваха пред едни и същи специализирани съвети на ВАК и при еднакви условия, при което, съвсем теоретично, кандидат от университета в Долно Нагорнище можеше да не успее да покрие изискванията и да не защити.

ЗРАСРБ също така замени термина “научно звание” с академична длъжност и премахна званията (старши) научни сътрудници, приравнявайки ги на университетските съгласно схемата:

научен сътрудник → асистент
ст.н.с. II степен → доцент
ст.н.с. I степен → професор

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

И какво от това?

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

Така че:

не съм длъжен да преподавам;
преподавам, защото мога и имам какво да кажа;
правилното формално обръщение към мен е “д-р Илиев”;
не държа на включването на степента в неформална среда, поне докато не стана професор;
не мога да лекувам болести, в това число язва, артрит, грип, синузит, главоболие, болки в кръста и ставите, венерически болести.

Речник на някои изрази и термини

стария закон
Закон за научните степени и научните звания (ЗНСНЗ), действал до средата на 2010 г., отменен от новия закон (ДВ бр.38 от 2010 г.)
новия закон
Закон за развитието на академичния състав в Р. България (ЗРАСРБ), голяма част от точките в който бяха обявени за противоконституционни от Конституционния съд на Р. България с РКС №11 от 2010 г. и изменени впоследствие (ДВ бр.101 от 2010 г.).
хабилитация
придобиване на най-висока научна квалификация

Отказ от отговорност

Възможно е да не съм представил правилно някои от законовите аспекти – не съм адвоткат все пак, а част от другите да съм пречупил през собствената си призма. Докато четете това, аз стоя с кръстосани пръсти :)

tl;dr

Доктори, доктори… Абе, всички са маскари…

Един месец с PocketBook

Thu, 11 Nov 2010 22:51:18 +0000

Ето че измина малко повече от месец, откак в колекцията ми от (не-)нужни електронни джаджи се нареди и PocketBook 301+. Идеята е по-долу да опиша опита от едномесечното му използване, но неминуемо ще се получи някакъв хибрид между описание и ревю.

Програмно осигуряване

Програмното осигуряване на самия PocketBook 301+ е почти безупречно, като изключим някои забележки. Съпътстващо компютърно програмно обезпечение на практика не е необходимо, тъй като взаимодействието с устройството става през USB Mass Storage интерфейс (за достъп до вътрешната памет) или посредством четец за SD карти и се свежда до просто копиране на файлове. Поддържат се толкова много файлови формати, че необходимост от конвертиращи програми няма. Разбира се, хората с големи библиотеки от електронно съдържание биха могли да се възползват от някаква каталогизираща програма, като например calibre. Моят опит с calibre под OS X обаче беше направо плачевен, в контраст на доброто старо ръчно копиране, което работи безотказно.

Съществува и една програма, PocketNews, достъпна от страниците на производителя, която може да преобразува RSS потоци във FB2 книга за четене върху PocketBook (да не се забравя, че PB301 няма мрежова свързаност). Освен че е грозна (на външен вид), програмата е само за Windows, поради което не намери абсолютно никакво приложение в живота ми.

На два пъти имах щастието да мина и през процедурата по обновяване на фърмуера – първо от 14.2 до 15.2, след което отново до 15.2, но от друга дата (минус за производителя е липсата на допълнителна диференциация във версиите на фърмуера; от друга страна поне слагат датата на пакетиране в името на архива за разлика от Pentax…). Проблеми, за щастие, не се появиха. Любопитна особеност е, че обновяването се прави от файл, записан на SD картата или във вътрешната памет на устройството, но не започва, ако то не е свързано с външен източник на захранване, дори батерията да е заредена напълно. Самото обновяване отнема не повече от минута-две. Ефектът като цяло беше, че се появиха потребителски профили за настройките (които не ми трябват, тъй като, поне за момента, само аз използвам е-четеца) и варианти на режима на опресняване на екрана (по-подробно – в следвата секция).

Екран с електронно мастило

Освен че са бавни, основен недостатък на екраните с електронно мастило е, че при частично обновяване на екрана, част от предишното изображение може да остане видима под формата на блед “призрак”, било то като тъмни области по белите места или като светли области по тъмните места на новата страница. По тази причина смяната на страниците се предхожда от цялостно почерняне и последващо избелване на екрана (процес, който нататък ще наричам за по-кратко само избелване). Екранът на PocketBook 301+ се обновява с доста малко тъмни призрачни остатъци, поради което в новите версии на фърмуера има опция избелването да се прави само през определен брой страници – 3, 5, 10 или изобщо да не се прави. При добро осветление няма проблем да се избелва и през 10 страници – така хем страниците се “прелистват” по-бързо, хем екранът консумира по-малко електрическа енергия. Контрастът на буквите обаче постепенно се влошава до следващото избелване, поради появата на светли точки в тях, дори при избор на получер шрифт. Поради това оставих включена опцията да се избелва преди всяка нова страница.

Тук е моментът да вметна, че въпреки приличните шрифтове, с които идва PocketBook, съществува възможност за добавяне на допълнителни такива. По съвет на няколко потребители от форума MobileRead, добавих шрифтовете Droid от комплекта свободни шрифтове в Android (достъпни в хранилището на Android тук). Мога да кажа, че Droid Serif изглежда много по-приятно от подразбиращия се безсерифен шрифт на PocketBook.

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

Осветлението е всичко

Тъй като екраните с електронно мастило работят на принципа на отражението, то външното осветление е съществен елемент за качеството на показваното изображение. На дневна светлина e-Ink екранът на PocketBook изглежда светло сив, прилично на стар вестник. Такъв остава и на луминисцентно осветление. На светлината от крушка с нажежаема жичка обаче, особено при слаб интензитет, се появява слаб зеленикав оттенък, като четимостта на текста намалява малко. Подозирам, че последното е свързано по-скоро с особеностите на моето зрение, тъй като се проявява и при четене на книги, отпечатани върху некачествена хартия (вас гледам, Б**Д). Четенето вечер е възможно на дифузната светлина на насочена към стената нощна лампа с нажежаема жичка, но все повече се замислям за бяла светодиодна лампичка за четене (от типа на онези с щипка за закрепване върху твърди корици).

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

Файлови формати

PocketBook е кралят на неспецифичните формати за електронно съдържание. Ще започна с ePub. Въпреки, че ePub е нещо като есперантото сред форматите за електронни книги, това не е оптималният формат за PocketBook. Устройството разполага с две приложения, които визуализират ePub – fbreader и AdobeViewer (реализация под лиценз на Adobe Digital Editions). fbreader не се справя добре с CSS стиловете в ePub книгите, докато AdobeViewer, макар и да може да изобразява защитени с DRM книги, не може да показва кирилица и диакретични знаци.

И доколкото ePub файловете все пак стават за четене, то истинският формат за PocketBook е любимият във всички рускоговорящи страни (пък и у нас) FB2, както и архивираният вариант FB2.ZIP. Удобното за този формат е, че се поддържа автоматично сричкопренасяне, дори за български текстове, което прави запълването на редовете много по-приятно.

Забележки

Има обаче един дразнещ елемент в реализацията на бележките под линия във FB2. В ePub бележките са подредени една след друга в края на всяка глава, а вътре в текста има номерирани препратки¹. Когато на една страница има множество² бележки³, то обикновено е достатъчно да се проследи само първата от тях, след което да се прочете и текста на останалите, без да е необходимо връщане и ново проследяване на следващата препратка. Не така обаче стои въпросът при FB2, където бележките са обособени в структурата на самия файл, при което се показва само текстът на избраната бележка. Достигането до бележката и връщането обратно е тежък процес: първо се натиска “Надолу”, с което се активира режимът за проследяване на препратки и автоматично се маркира първата от тях; ако е необходимо, с последователно натискане на “Надолу” се избира желаната препратка; с “ОК” се проследява препратката до текста на бележката; с натискане на “Надолу” отново се преминава в режим на проследяване на препратки, което автоматично избира новопоявилата се стрелка за връщане назад; натиска се “ОК”. Прочитането на страница с 5 бележки означава допълнително 15 натискания на “Надолу” и 10 натискания на “ОК”. Тежко и горко на четящите Умберто Еко :)

Поддръжа се и DjVu, което е направо безценно поради изобилието на сканирана научна литература, която в наши дни се намира много трудно като хартиени издания. Например 10-те тома на курса по теоретична физика на Ландау и Лифшиц изглеждат на PocketBook досущ като печатните оригинали. Форматът поддържа текстов слой, даващ възможности за търсене, както и вътрешни препратки, но все още не съм имал възможността да изпробвам тази функционалност поради липса на файлове с подобна организация на съдържанието.

PDF файловете се четат без проблеми, като при тях най-съществена е възможността да се игнорира положението и големината на текстовите елементи и текстът да запълни цялата страница – т.нар. Reflow режим. Не е подходящ за богати на графични елементи документи (напр. ръководството на потребителя на Pentax K-x), но върши работа за статии и книги с много тесни колони текст и широки полета.

Издръжливост на батерията

Времето за автономна работа е това, което силно отличава четците с електронно мастило от останалите видове устройства с матрични екрани, били те LCD (с LED или CFL подсветка), LED или OLED. След първоначалното 12-часово зареждане на батерията (с твърде спорен кондициониращ ефект), допълнителни зареждания от по 2-3 минути съм правил само по време на обновяване на фърмуера. След като изчетох над 1500 страници и си играх многократно с менютата за настройка, индикаторът на заряда на батерията е по средата. Екстраполацията на пръсти показва, че ако само се чете, то капацитетът стига за поне 4000 страници (а производителят обещава 8000). За справка: “Името на розата” е 856 страници при най-удобния за мен размер на буквите.

Удобство при използване

Удобството е силно субективно усещано качество. Мога да кажа, че PocketBook 301+ е достатъчно удобен, поне за мен. Има трески за дялане – все пак, това е един от първите модели на производителя му. Може да се ползва както със, така и без предпазен калъф. Корпусът е пластмасов, със солидна изработка и нещо като гумирано покритие. Изглежда удобно, че не се хлъзга, но на мен ми е някак странно на пипане – като топче от мишка е (помните ли времената, когато мишките не бяха оптични?). Затова не вадя четеца от предпазния калъф, което, освен всичко друго, придава и усещането, че държа тефтер с кожена подвързия. В различните окомплектовки има различни типове калъфи, като моят е с нещо като кожен джоб с изрязано лице. Малко грозно е ушит, но пък е функционален и с магнитно затваряне. Предната корица може да се прилепи за задната (с вградените магнитчета) и се получава достатъчно твърда основа с удобна за хващане ширина.

Навигацията се осъществява с джойстик, подобен на Navi клавиша в повечето модели Nokia. Функцията на всеки един от контактите на джойстика, както и на бутоните отстрани на корпуса, може да се променя в настройките на устройството, което позволява на всеки да го направи максимално удобно за себе си. Наличието на потребителски профили във версия 15.x на фърумера пък позволява избягване на ситуации от вида “Ама защо си ми разбърникал настройките!!”. Джойстикът за навигация отнася доста щракания, особено ако в текста има множество препратки, както вече споменах. Конструкцията му изглежда достатъчно стабилна и за момента не очаквам да се счупи в скоро време.

Заключение

В заключение мога да кажа, че въпреки че PocketBook 301+ няма дизайна на четците на Sony, нито безжичните мрежови възможности на Kindle и Nook, то той лека полека се превръща в неизбежен инструмент от ежедневието ми.

Както е типично за повечето ми покупки на изчислителна техника до момента, цената на PB301 падна значително, дни след като го взех. Все пак не съжалявам за вложените средства и смятам, че това е един от най-добрите подаръци, които съм си правил в чест на годишнина от появата ми този свят.

Нещо такова. ↩︎
И такова. ↩︎
Ето ни в края. ↩︎

Петък вечер

Fri, 29 Oct 2010 20:56:39 +0000

Дяволът намира работа за geek-овете, които си нямат друга такава:

Benchmarking: Traditional DES [128/128 BS SSE2-16]... DONE
Many salts: 229334K c/s real, 229587K c/s virtual
Only one salt: 196838K c/s real, 196838K c/s virtual
Benchmarking: BSDI DES (x725) [128/128 BS SSE2-16]... DONE
Many salts: 7469K c/s real, 7469K c/s virtual
Only one salt: 7261K c/s real, 7261K c/s virtual
Benchmarking: FreeBSD MD5 [32/64 X2]... DONE
Raw: 1032K c/s real, 1032K c/s virtual
Benchmarking: OpenBSD Blowfish (x32) [32/64 X2]... DONE
Raw: 62009 c/s real, 62016 c/s virtual
Benchmarking: Kerberos AFS DES [48/64 4K]... DONE
Short: 34259K c/s real, 34259K c/s virtual
Long: 107373K c/s real, 107373K c/s virtual
Benchmarking: LM DES [128/128 BS SSE2-16]... DONE
Raw: 1162647K c/s real, 1162649K c/s virtual

ДжобнаКнига

Sat, 16 Oct 2010 22:19:45 +0000

Той е дебел само 8.5 мм и тежи едва 174 грама. Има 6” Vizplex екран с контраст на стар вестник от рециклирана хартия. С гъстота от 166 dpi и цели 16 нива на сивото буквите изглеждат като напечатани върху него. Литиево-полимерната му батерия обещава безпроблемно прелистване на няколко хиляди страници, при което той не се превръща в безформена дрипа. Ако буквите му ви се струват малки, просто натискате бутона +. Ако не ви харесва нечетливият едър шрифт в стил и.к. Б*РД (чиито книги биха станали двойно по-тънки и дори биха ставали за четене, ако заложат на типогрфията, а не на количеството страници), просто качвате нов в /system/fonts и го избирате от настройките. Той поддържа PDF (с Reflow), ePub, DjVu, FB2, CHM и някои други, които дори не знам къде се ползват. И не, той няма лъщящо сензорно стъкло, разположено над E-Ink пакета, нито WiFi, нито СинЗъб, нито пряка 3G връзка към Amazon или Barnes & Noble. Той има просто слот за SD карти с обем до 32 GB. И не изисква iTunes-подобна програма – просто записвате файловете на картата или във вътрешната памет през mini-USB порта. Той е идеален за четене в тоалетната на поредната купчина научни статии в PDF или на “онази безобразно напечатана книга, дето не става за четене, но пък в читанката я има на ePub”. Той разбира и от DjVu, така че “ония дискове от Колхоза” могат да влязат в употреба и човек да се поизучи малко, па макар и не особено законно (но пък законно ли е, че държавата задушава най-реномираните си университети, след което главният пожарникар, пардон, министър-председателят, ги упреква, че чакали на бюджета). Слушат ви се аудио-книги? Няма проблем – той просвирва и MP3.

А като ви писне да четете, може да да поиграете шах, или судоку, макар управлението с джойстика да е малко терсене. Ако знаете някоя друга игра и ви влече писането на програми под Linux, то той си има и SDK.

Дразни ви темата? Няма проблем – редактирате един няколкостотинредов файл, слагате свои картинки, компилирате темата с достъпната от сайта програма и той изглежда точно така, както вие го искате.

Той се произвежда в Китай (но и iPad се произвежда там, мм?), а се програмира в Украйна. Затова няма проблеми с кирилицата в нито един от поддържаните формати. И с китайските йероглифи няма, стига да си качите допълнителните шрифтове. А наличието на Adobe Reader му позвлява да чете дори книги с DRM защита, макар AR да се вълнува до извъпросителняване от кирилицата в ePub книгите.

Той не е Kindle. Той не е Nook. Той дори не е на Sony. Той е просто PocketBook 301+ – (само-)подарък за поредната обиколка на Земята около Слънцето от онзи фиксиран момент в миналото…

(източникът на снимката е недвусмислено отбелязан върху нея)

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

За впечатленията от устройството и последствията от продължителното четене от електронната хартия ще напиша след време.

П.п. Няма да обяснявам защо се сдобих точно него, след като останалата ми техника, без телефона е на Apple. Феновете няма да ме разберат, а другите просто няма да попитат…

Ода за некомпетентността

Wed, 11 Aug 2010 08:38:08 +0000

Internet – it doesn’t make you stupid, it just makes your stupidity more accessible to others.

Не знам с какви други думи да опиша възмущението си от ширещите се от известно време в родната Мрежа некомпетентност и графомания, които напоследък достигат такива застрашителни размери, че мисълта да добавя *.bg към списъка от филтри на AdBlock започва да се материализира със страшна сила.

Капката, която преля чашата, е умопомрачителното графоманско творение, в което лицето VaGro открито защитава посегателството върху един от най-важните за бедната ни ~~бананова~~ аграрна република институт на БАН с позицията, че метеорологията в България е излишно пилеене на средства. И наистина, за какво им е на земеделците у нас прогноза за възможни градушки, след като противоградовите комплекси вече ги няма и градушката така или иначе ще се изсипе с цялата си сила? За какво ѝ е на държавата да знае кога реките ще прелеят, след като и без това пътищата и мостовете ще пропаднат, а хората все някак ще се оправят с унищожените си домове и покъщнина? На държава, която ~~замазва~~ решава всичките си проблеми post factum, превантивни мерки не ѝ трябват.

Според въпросния господин, нужда от метеорологичен институт в България няма, тъй като той се бил осланял на прогнозите на weather.com, пък и съседните държави си имали прогнози за времето. Повърхностното мислене и липсата на елементарна компетентност в областта, характерно за графоманите с пренадуто его, обаче му пречат да осмисли факта, че метеорологията е многомащабна наука, която използва както глобални, така и силно локални източници на информация, благодарение на които се формират т.нар. гранични условия на моделите. Пречи му да осмисли, че едромащабните глобални и континентални прогнози се рафинират с дребномащабни локални модели, използвайки данни от стотиците метеорологични станции във всяка една страна. А всички метеорологични модели са хаотични по природата си динамични системи и малките отклонения в граничните условия могат да скрият ураганите в правилните предсказанията, превръщайки ги в прекрасни слънчеви дни. И да, съседните ни държави наистина са умрели за данните, които НИМХ им подава, защото без тях метеорологичните им прогнози струват толкова, колкото и тези на ТВ шаманите, гадаещи на кафе, боб, кости и зарчета. А без пари за поддръжката на станциите у нас, драги ми VaGro, единственото, което ще гледаш във weather.com, ще бъде надписа “No data/No weather station”.

Чукча обаче писател, чукча не читател. Чукча мрази да мисли – по-лесно е да действа първосигнално, а в оставащото свободно време да залива Мрежата с помията си. Поне не излиза скъпо – дисковото пространство и мрежовият обмен са вече почти без пари…

Ах тези префикси

Sat, 10 Jul 2010 22:15:29 +0000

Имаше един такъв виц за студентите от ФМИ, че на влизане там мислели, че един килобайт е 1000 байта, а на излизане били убедени, че един килограм е 1024 грама. Изглежда същото важи с пълна сила и за възпитаниците на един от най-реномираните американски университети, разработили софтуера за наблюдение на големи компютърни системи Ganglia.

Преобразуване на мегахерци в гигахерци, в стил Berkeley.edu:

От доста време ми правеше впечатление, че уеб частта на Ganglia систематично подценява работната честота на процесорите на наблюдаваните машини, но, честно казано, дори не ми е минавало през ума, че е възможно причината да бъде в погрешна интерпретация на префикса на честотата. Още по-изумителното е, че за толкова години никой не е забелязал грешката!

computo ergo sum

(Отново) За паралелното програмиране

Вместо увод

Паралелни архитектури

SIMD и VLIW

Програмни модели

Практически примери

Реформа №2

Реформа

22.11.2013

Сбогом, Twitter!

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

Проблемът

Методът

Призивът

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

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

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

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

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

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

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

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

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

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

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

Последната линейка на София

За щастието

Една година в Германия

Интервал

!dead

Лекция на OpenFest 2011

Bitcoin - митове и легенди (част 2)

Сравнение с експерименталните наблюдения

Bitcoin - митове и легенди (част 1)

Малко предварителна информация

Основна заблуда: блоковете имат предварително определен размер; има големи и малки блокове

Втора основна заблуда: късметлии и каръци

След “голям” блок се чакат “малки” блокове

Смяна на басейна за избягване от “лош късмет”

Краят на една епоха

Наука с Physon (2011)

Обратно на линия

Лайняната работа

Кратката версия

Дългата версия

Another job well done!

Кофите на бъдещето

Магнитните топчета

PocketBook 301+ с/у Kindle 3

Спецификация на устройствата

Снимките

В резюме

Post factum

tl;dr

Доктори, доктори...

Промени в новия закон

И какво от това?

Речник на някои изрази и термини

Отказ от отговорност

tl;dr

Един месец с PocketBook

Програмно осигуряване

Екран с електронно мастило

Осветлението е всичко

Файлови формати

Забележки

Издръжливост на батерията

Удобство при използване

Заключение

Петък вечер

ДжобнаКнига

Ода за некомпетентността

Ах тези префикси

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