Колко виртуална е виртуалната машина на SBCL?

Както стана ясно в предишния пост, посредством defun се дефинира функция: на съответното име се присвоява списък от форми, които при извикването на функцията се оценяват (т.е. изпъляват) една след друга. ANSI Common Lisp стандарта не уточнява дали по време на дефиницията на функцията формите се превеждат до някакъв byte code или каквото и да било друго, стига при оценяването да се случва това, което е указано в сорс кода. С прости думи -- не става ясно дали еval действа като интерпретатор или като компилатор и ако действа като компилатор, до какъв код компилира. Всяка имплементация на стандарта е свободна да процедира както намери за добре.

Фен-бойчетата на C# и Java знаят, че техните компилатори превеждат до byte code -- някакво вътрешно представяне със специализирани инструкции, които виртуалната машина по някое време (най-често по време на изпълнението) превежда до машинен код за съответния процесор. В Microsoft средите на това му викат Common Language Runtime (CLR), а в Java средите не знам какво му викат, ама е точно толкова дебилно.  Защо eval да не създава код, който директно да се изпълява на съответната физическа машина? Знам какво ще чуя: защото не е преносим. И какво от това -- нали сорс кода, бидейки прост текст, е преносим? И ако за съответната платформа има виртуална машина, която по зададен сорс код може да създаде вътрешно представяне, защо трябва да се интересувам от това, дали вътрешното представяне на една архитектура е същото като на друга? Просто разпространявам сорс кода и всичко е ОК. Естествено, това е в разрез с Enterprise мисленето, но пък моята теза е, че именно Enterprise мисленето е в основата на всичко зло. Така че това не е довод, поне не пред мен.

Аз използвам имплементацията SBCL -- Steel Bank Common Lisp. Последните две думи (Common Lisp) са ясни -- името на диалекта, за който си говорим. Първите две (Steel Bank) са бъзик с CMU-CL, чийто fork e SBCL. Университета Carnegie Mellon University (CMU) e именован на Andrew Carnegie -- крупен стоманен (Steel) магнат в Щатите в началото на XX век, и Andrew Mellon -- водещ банкер (Bank) по същото време.

В тази имплементация нещата седят по следния начин: всяко дефинране на функция води до създаването на списък от инструкции, които могат директно да се изпълнят на съответния процесор, на който се е случило това дефиниране. Това има следния недостатък -- ако компилирам нещо върху X86_64, няма да мога да го ftp-осам на PPC машина и да го изпълня там. Но на кой му пука за този use-case така или иначе? Затова пък кода, който е генериран не отстътва по бързодействие на аналогичен код, компилиран със C компилатор. И за да не съм голословен, ще приведа следния пример:

CL-USER> (defun bahor (i j) (+ i (* 2 j)))

BAHOR

Това вече трябва да е ясно на всички, чели предишния пост. Дефинираме функция bahor, която по зададени парметри i и j връща стойност i+2*j. Наблюдавайте сега:

CL-USER> (disassemble #'bahor)

; disassembly for BAHOR

; 05C102CD:       488B55F0         MOV RDX, [RBP-16]

;      2D1:       BF04000000       MOV EDI, 4

;      2D6:       4C8D1C25B9020020 LEA R11, [#x200002B9]

;      2DE:       41FFD3           CALL R11

;      2E1:       480F42E3         CMOVB RSP, RBX

;      2E5:       488BFA           MOV RDI, RDX

;      2E8:       488B55F8         MOV RDX, [RBP-8]

;      2EC:       4C8D1C25E0010020 LEA R11, [#x200001E0]

;      2F4:       41FFD3           CALL R11

;      2F7:       480F42E3         CMOVB RSP, RBX

;      2FB:       488BE5           MOV RSP, RBP

;      2FE:       F8               CLC

;      2FF:       5D               POP RBP

;      300:       C3               RET

;      301:       CC0A             BREAK 10

;      303:       02               BYTE #X02

;      304:       18               BYTE #X18

;      305:       54               BYTE #X54

NIL

Опаааа -- какво имаме тук? Първо -- имаме стандартна функция disasseble, която изпечатва листинг на машинния код + асемблера за съответната функция (само помислете колко софтуер трябва да инсталирате, за да получите същата информация за дадена функция на C, не дай си боже на Java). И второ -- машинния код както можем да видим е съставен от инструкции за (в случая) 64-битов X86 процесор.  И понеже имам достъп и до PowerPC машина, ето как изглежда аналогичния изход там:

CL-USER> (disassemble #'bahor)

; disassembly for BAHOR

; 5119667C:       92EF0004         STW $LRA,4($CFP)

;      680:       830F0010         LWZ $A0,16($CFP)

;      684:       3B200008         ADDI $A1,$ZERO,8

;      688:       3AF30070         ADDI $LRA,$CODE,112

;      68C:       3CE00400         ADDIS $NL4,$ZERO,1024

;      690:       38E70360         ADDI $NL4,$NL4,864

;      694:       7CE803A6         MTLR $NL4

;      698:       4E800020         BLR

;      69C:       00000000         BYTE #X00, #X00, #X00, #X00

;      6A0:       00001C36         BYTE #X00, #X00, #X1C, #X36

;      6A4:       7ED0B378         MR $CSP,$OCFP

;      6A8:       60000000         NOP

;      6AC:       3A77FF90         ADDI $CODE,$LRA,-112

;      6B0:       7F19C378         MR $A1,$A0

;      6B4:       830F000C         LWZ $A0,12($CFP)

;      6B8:       3AF300A0         ADDI $LRA,$CODE,160

;      6BC:       3CA00400         ADDIS $NL2,$ZERO,1024

;      6C0:       38A50200         ADDI $NL2,$NL2,512

;      6C4:       7CA803A6         MTLR $NL2

;      6C8:       4E800020         BLR

;      6CC:       00000000         BYTE #X00, #X00, #X00, #X00

;      6D0:       00002836         BYTE #X00, #X00, #X28, #X36

;      6D4:       7ED0B378         MR $CSP,$OCFP

;      6D8:       60000000         NOP

;      6DC:       3A77FF60         ADDI $CODE,$LRA,-160

;      6E0:       806F0000         LWZ $NL0,0($CFP)

;      6E4:       82EF0004         LWZ $LRA,4($CFP)

;      6E8:       7DF07B78         MR $CSP,$CFP

;      6EC:       7C6F1B78         MR $CFP,$NL0

;      6F0:       3BF70005         ADDI $LIP,$LRA,5

;      6F4:       7FE803A6         MTLR $LIP

;      6F8:       4E800020         BLR

;      6FC:       00000000         BYTE #X00, #X00, #X00, #X00

NIL

Вижда се, че SBCL компилира/интерпретира до машинен код. Т.е. на въпроса колко виртуална е виртуалната му машина -- отговора е "много малко виртуална е".

В този момент C фанатиците доволно потриват ръце и си викат "толкова много код за едно умножение и едно събиране? -- това очевидно не е оптимално". В който момент аз почвам да обяснявам как този код е в състояние да обработи всякакви стойности за i, j  и върнатия резултат, стига да се събират в паметта, независимо дали са цели числа, рационални дроби или floating point и давам следния пример:

CL-USER> (bahor 10000000000000000000000000000000000000000000000000000000000 7/19)

190000000000000000000000000000000000000000000000000000000014/19

(това между другото е числото 10 на 58-ма степен + два пъти по 7/19, което е равно на рационалното число, получено като резултат на последния ред)

Но те продължават -- "Е да де, ама аз не искам такива сложнотии, аз искам i и j да са простички цели числа, които се събират в регистри на съответния процесор; резултатa и той се събира в такъв регистър, сигурен съм! И тогава това е overkill, защото не ме интересува колко е всеобхватно, аз искам да е бързо!"

За такива случаи в Common Lisp е предвидено програмистът да може да укаже на компилатора какви всъщност са типовете на променливите. Но забележете -- само с цел оптимизация, а не промяна на семантиката! Функцията ще работи и без да й указвате какви са типовете на променливите; ако ги укажете може просто да заработи по-бързо, но крайния резултат ще е един и същ! 

И така, нека да опитаме да укажем типовете, като променим кода да изглежда така:

(defun bahor (i j)

  (declare (optimize (speed 3) (safety 0)) (fixnum i j))

  (the fixnum (+ i (* 2 j))))

Имаме един допълнителен ред, който започва с declare, в който се казват следните неща преведени на Български: компилаторе, искам да оптимизираш тази функция за бързодействие (speed 3), без да се интересуваш дали типовете на аргументите, които ти подавам, съответстват на истината (safety 0) и променливите i и j са от тип fixnum (Без да изпадам в подробности ще кажа, че съгласно стандарта, променливи от тип fixnum се събират в регистър). Другата промяна е на последния ред, в който казваме "... върнатия резултат и той ще се събере в регистър". И тогава (на x86-64):

CL-USER> (disassemble #'bahor)

; disassembly for BAHOR
; 0351C4F5:       48D1E7           SHL RDI, 1
;      4F8:       4801FA           ADD RDX, RDI
;      4FB:       48D1E2           SHL RDX, 1
;      4FE:       488BE5           MOV RSP, RBP
;      501:       F8               CLC
;      502:       5D               POP RBP
;      503:       C3               RET
NIL
CL-USER> 

а на PowerPC:


CL-USER> (disassemble #'bahor)
; disassembly for BAHOR
; 5119D20C:       54A6083C         RLWINM $NL3,$NL2,1,0,30
;       10:       7CC43214         ADD $NL3,$NL1,$NL3
;       14:       54D8103A         RLWINM $A0,$NL3,2,0,29
;       18:       7DF07B78         MR $CSP,$CFP
;       1C:       7ECFB378         MR $CFP,$OCFP
;       20:       3BF70005         ADDI $LIP,$LRA,5
;       24:       7FE803A6         MTLR $LIP
;       28:       4E800020         BLR
;       2C:       00000000         BYTE #X00, #X00, #X00, #X00
NIL

Смея да твърдя, че това е съизмеримо с кода, който генерира произволен C компилатор за подобна функция. И какво излиза -- ако искаме всеобхватност, просто пишем кода; той работи  за всякакви случаи; ако искаме бързодействие и знаем какво правим, можем да го декларираме и ще получим каквото искаме. Ето това за мен е мощна и смислена платформа -- по принцип може да работи за всички случаи, а ако съм много умен, може да го накарам да работи и бързо. А не като Java-та -- каквото и да правиш, все е бавно...

Лека нощ, драги зрители!

(здравей-свят)

Имам намерението да ви разкажа в рамките на известен брой публикации за благините на Lisp. Надявам се да ви стане интересно и да получите една различна гледна точка към програмирането. Наясно съм, че конюнктурата не позволява да седнем и да си изкарваме хляба на Lisp в момента -- за съжаление сме "женени" за някакви технологии и няма да получим лесно развод, но това че сме си поръчали, не означава, че не можем да разглеждаме менюто, нали така?

Теоретична подготовка

Преди да се втурнем да реализираме "Hello, World!" не е лошо да вкараме малко теоретична подготовка. Lisp е изведен преди 55 г. и е вторият най-стар език за програмиране от високо ниво -- само FORTRAN е с 1 г. по-стар от него. Като казвам "изведен",  имам предвид именно това -- той е изведен математически и това го отличава от всички останали упражнения по строене на пясъчни кули под формата на езици за програмиране. Хард-кор феновете могат да прочетат оригиналната статия на John McCarthy от 1958 г. тук. Аз няма да й обръщам много внимание, само ще отбележa, че подобно на машината на Тюринг и тук става въпрос за съвсем малък набор от примитиви (ако не ме лъже паметта 7 на брой), чрез които може да се изгради всеки възможен алгоритъм.

Бидейки на 55 г. Lisp е еволюирал дълго, като през това време е дал началото на концепции като виртуална машина, garbage collection, exception handling, та дори и на конструкцията if-then-else. В началото на XXI век има няколко живи диалекта на Lisp, като най-смисленият за мен се казва Common Lisp. Той е стандартизиран от ANSI и е достатъчно освободен (за разлика напр. от Scheme) за да е всъщност полезен.

Lisp е дефиниран като homoiconic език и е първият такъв. На Български това означава, че програмата на Lisp се представя посредством същата структура, с която се представят и данните. Това позволява на дадена Lisp програма да създава, променя и както си иска да манипулира части от Lisp код, вкл. части от своя собствен, без при това да се налага допълнително писане на парсери, генератори на двоичен код, компилатори и т.н. Сега, радетелите за чиста и свята република ще почнат да обясняват колко е вредно да пишем само-модифициращ се код. И сигурно са прави донякъде. Само че ако лежим на тая кълка по-добре да ходим да пасем овцете, защото всяка девелопърска станция без изключение прави точно това: съвкупността от инсталиран софтуер ни позволява да създаваме, променяме и манипулираме други програми, които стават част от инсталирания софтуер. А, и освен това ни позволява да се създаваме, променяме и манипулираме данни по същия начин. С други думи: Lisp изпълнява ролята на цяла (development) машина, от там и термина "виртуална машина". При това всичко се случва по дефиниция, а не защото някой се е сетил (или не се е сетил съответно) да напише компилатор за C и сега се опитва да ни го продаде на промоция за $800 долара.

REPL

Като всяка нормална машина, и виртуалната машина на Lisp, когато я стартираме показва промпт (въпрос към Java фен-бойчетата: защо тяхната виртуална машина не прави така?). Има и един друг съвременен език, по който хората напоследък са луднали, който прави същото: нарича се Python. На Lisp-а промпта се нарича REPL и е съкращение от Read-Eval-Print-Loop -- т.е. прочитаме какво иска да ни каже потребителя (Read), изпълняваме го (по-правилния термин е оценяваме го) (Eval) и изпечатваме резултата (Print); след това почваме от начало (Loop). Просто като боб. Ето как изглежда REPL промпта обикновено:

CL-USER>

(Това преди знака за по-голямо е името на текущия package, което е нещо като namespace-ите на C++, C# и package-ите в Java, но затова -- друг път.)

Има нещо изключително важно, което се съзира след внимателен прочит на горното и това е, че всяко нещо, което Lisp може да прочете си има стойност. Именно намирането на тази стойност е задача на оценяването (Eval).

Форми и оценяването им

Програмите/данните на Lisp се състоят от неща, които се наричат форми. На най-ниско ниво Lisp разбира от два вида форми: атоми и списъци. Атомите са единични неща, като напр. числото 5, стринга "БАХОР" или името PI (терминът, който се използва в Lisp за означаване на име е символ (symbol). Да не се бърка със символ в смисъла на char). Списъците от своя страна се записват по възможно най-простия начин: като поредица от атоми заградени в кръгли скоби (например този наклонен текст тук в скобите е списък).

Числата и стринговете са self-evaluating, т.е. резултата от оценяването им е присъщата им стойност:

CL-USER> 5
5
CL-USER> "БАХОР"
"БАХОР"

(Тук 2-ри и 4-ти ред показва резултата от Print частта на REPL).

Когато става въпрос за символ, като напр. PI, резултата е стойността, която в момента е свързана с това име:

CL-USER> PI
3.141592653589793d0

Свързването (binding) прилича малко на присвояването (assignment), но не е същото, но затова друг път. За целите на настоящия пост е достатъчно да си мислим, че в случая променливата PI има стойност 3.141592653589793d0, която Eval частта на REPL е намерила и съответно Print частта е изпечатала.

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

CL-USER> (cos (/ pi 2))
6.123233995736766d-17

Най-напред имаме списък от 2 елемента: първият е символа cos, а вторият е списъка (/ pi 2). Първият елемент се разглежда като име на функция. Има ли такава функция? Има, да, както се сетихте това е функция с един аргумент, имащ смисъла на ъгъл в радиани, и нейната стойност е косинуса от този ъгъл. След като има дефинирана такава функция, остава да я изпълним. За целта обаче трябва първо да се оценят аргументите й, т.е. останалите неща в списъка, а това е от своя страна списъка (/ pi 2). Първия елемент от този списък е символа /, а втория и третия са съответно името pi и числото 2. Има ли дефинирана функция / -- има, тя дели първият си аргумент на всички останали аргументи. Остава да оценим нейните аргументи. Те са атоми и следователно се оценяват както е описано по-горе. Делението се изпълнява и резултата от него PI/2 се използва като аргумент за функцията cos. Сега от своя страна се изпълява и тя и резултата е някакво много близко до нула число (както знаем от Студ. град -- cos от 90 градуса = нула в чашката).

Вариации на тема "Здравей, Свят!"

Първи вариант:

CL-USER> "Здравей, Свят!"

"Здравей, Свят!"

Нищо ново -- Lisp прочете стринга, който му написах, оцени го като самия себе си и ми го изпечата обратно.

Втори вариант:

CL-USER> (format t "Здравей, Свят!~%")

Здравей, Свят!

NIL

Това, което се случва тук, е функцията format. Тя има същата роля както fprintf в C. Първия й аргумент е stream, към който да изпрати изхода. В случая със символа T (който по дефиниция е свързан с булевата стойност True) се указва на функцията да прати резултата на стандартния изход. Следващия аргумент е форматиращия стринг, нищо по-сложно от fprintf. Това, което е по-различно е как се задават полета за печат. Тук, за разлика от C-то не се задават с процент (%), а с тилда (~). Това, което се вижда на края на стринга (~%) е еквивалента на \n в C. Изключително мощна е конструкцията ~A, която печата съответния аргумент в естетически формат, т.е. така, че да е удобно да бъде прочетен от човек.

Прави впечатление, че след изпълнението на функцията се появяват 2 реда. Това е така, защото първия ред е изхода, генериран от функцията и изпратен на стандартния изход, а втория ред е самата стойност на функцията, т.е. резултата от Eval-а (в случая този резултат е NIL -- символ, обратен на T, който по дефиниция е свързан с булевата стойност False). Тук се наблюдава т.н. страничен ефект -- функцията повлиява на обкръжението си освен със стойността си, и по друг начин (в случая изпечатването на стринг на екрана). В някои по-рестриктивни диалекти на Lisp, като например Scheme, страничните ефекти са забранени. Това обаче не е продуктивно и затова към Scheme има по-скоро само академичен интерес.

Трети вариант:

CL-USER> (format t "~A~%" "Здравей, Свят!")

Здравей, Свят!

NIL

Същото като преди, само че този път във форматиращия стринг е използвана конструкцията ~A, която печата стойността на съответния аргумент, в случая стойността на стринга "Здравей, Свят!". Това е едно към едно с fprintf(stdout, "%s\n", "Здравей, Свят!") на C.

Последен вариант:

CL-USER> (defun здравей-свят () (format t "Здравей, Свят!~%"))

ЗДРАВЕЙ-СВЯТ

CL-USER> (здравей-свят)

Здравей, Свят!

NIL

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

locate_image_and_perform_stuff_on_it

locateImageAndPerformStuffOnIt

locate-image-and-perform-stuff-on-it

последното е най-четимо. В Lisp практически няма (е, почти няма) ограничение за буквите и символите, които могат да присъстват в имената на променливи и функции. Затова и мога да дефинирам функция с име на Български, че ако искам и на Японски:

CL-USER> (defun 世界ようこそう () (format t "世界、ようこそう！~%"))

世界ようこそう

CL-USER> (世界ようこそう)

世界、ようこそう！

NIL

Втория  аргумент на defun е списък с аргументи за новата функция. В случая тя няма такива, затова списъка е празен. Останалите елементи от списъка на defun формират тялото на новата функция.

Резултата от изпълнението на defun (т.е. това, което се вижда на 2-рия ред) е името на дефинираната (или ре-дефинираната!) функция. Когато тя се извика (което става на 3-ти ред), формите в тялото й се изпълняват една по една. Резултатът от изпълнението на функцията е стойността на последната изпълнена форма от тялото й. В случая резултата е резултата от извикването на format, т.е. както и преди -- NIL.

Толкова за днес. Лека нощ, драги зрители, дано съм успял да Ви заинтригувам!

Нещо като OpenMP...на 27 реда код

Често (особено на чашка) съм се опитвал да обяснявам на хората, с които надигаме съответната течност, колко смислен e Lisp-а и колко безмислена -- Java-та. Този пост е още един пример в подкрепа на първото.

Става въпрос за високо-производителни изчисления (HPC). Знаем, че мулти-трединга, особено в контекста на съвременните многоядрени процесори, е един от механизмите за постигане на по-добра производителност. Когато говорим конкретно за математически изчисления (а и не само), едно от нещата, които се ползват от съответното комюнити е OpenMP. За тези, които не са наясно, с две думи: вместо да занимаваме нАучните работници да мислят в термините тредове, синхронизация, race conditions и др., им даваме достатъчно проста абстракция, с която да си раз-паралелят кода, като например следното (това съм го взел от Wikipedia, признавам си):

 1  int main(int argc, char *argv[])
 2  {
 3      const int N = 100000;
 4      int i, a[N];
 5  
 6      #pragma omp parallel for
 7      for (i = 0; i < N; i++) {
 8          a[i] = 2 * i;
 9      }
10
11      return 0;
12  }

Единственото странно нещо в този код е на 6-ти ред. Въпросната прагма указва на компилатора, че следващия стейтмънт (т.е. for-а с цялото си тяло) представлява всъщност паралелен for. Това е една от т.н. worksharing constructs, основна концепция в OpenMP, чиято семантика е следната: създават се няколко паралелни треда, които изпълняват тялото на цикъла; N-те итерации на цикъла се разпределят между тях; на края има имлицитна синхронизация, така че на ред 11 тредовете пристигат заедно (ако въобще пристигат до там няколко треда, защото би могло и да приключват на ред 9).

Разбира се в OpenMP има и куп други подобни благини, разни сложнотии и възможности за финно доизпипване на как точно искаме да ни се изпълни паралелния код, но в края на краищата, моя опит показва, че в 99% от програмите, които ползват OpenMP, 99% от конструкциите са parallel for.

Очевидно OpenMP е много смислено нещо. Използва се поголовно в световен мащаб. В него са наляти много време и пари, направен е консорциум, уеб-сайт, документация, пачнати са компилатори, направени са библиотеки и въобще бая труд е хвърлен за да се направи да работи. А то работи посредством специални издания на компилаторите, напр. за да проима идея за #pragma omp ..., даден компилатор трябва да е специално създаден за това. Още веднъж ще наблегна на това, защото е важно -- не е достатъчно само да свържете към кода си някоя библиотека, за да ползвате OpenMP -- трябва ви специален компилатор, който да разбира от съответните прагми. Има издания на повечето смислени компилатори за C/C++/FORTRAN, които кльопат директивите. gcc след версия 4.3.2 (ако не се лъжа) поддържа OpenMP по подразбиране.

Сигурно вече се питате "Aми за Java има ли го?". Само от уважение към колегите от EPCC към Университета в Единбург няма да нареча JOMP "абоминация", но сериозно си го мисля. Аз не смятам да обяснявам какво точно е JOMP, защото получавам позиви само като се сетя, но ако ви влече -- прочетете си го сами. Само ще кажа, че това е research проект, с няколко нАучни публикации, екип от нАучни работници и т.н. Искам да уточня -- не са виновни колегите, виновна е нефелната Java, на която дори да се издрайфаш не можеш като хората.

Та да си дойдем на думата. Викам си "след като това е толкова полезно и след като в 98% от случаите се използва конструкцията за parallel for, не мога ли да се опитам да си реализирам един такъв на Lisp?". И така -- седнах и за 1/2 час написах това:

 1  (defparameter *default-num-threads* (or (sb-posix::getenv "NUM_THREADS") 2))
 2 
 3  (defmacro dotimes* ((var count &optional (num-threads *default-num-threads*)
 4    (result nil)) &body body)
 5    (let ((thread-list (gensym "THREAD-LIST-"))
 6 (i (gensym "I-"))
 7 (q (gensym "Q-"))
 8 (r (gensym "R-"))
 9 (s (gensym "S-"))
10 (e (gensym "E-")))
11    `(let* ((,thread-list ())
12     (%num-threads ,num-threads))
13       (multiple-value-bind (,q ,r)
14    (ceiling ,count %num-threads)
15  (dotimes (,i %num-threads)
16    (let ((%thread-id ,i) ,s ,e)
17      (declare (ignorable %thread-id))
18      (if (< ,i (+ %num-threads ,r))
19   (setf ,s (* ,i ,q) ,e (+ ,s ,q))
20   (setf ,s (+ %num-threads ,r (* ,i (1- ,q))) ,e (+ ,s (1- ,q))))
21      (push (sb-thread:make-thread
22      #'(lambda ()
23   (do ((,var ,s (1+ ,var)))
24       ((>= ,var ,e) ,result)
25     ,@body)))
26     ,thread-list))))
27       (mapcar #'(lambda (th) (sb-thread:join-thread th)) ,thread-list))))

Забележете, че става въпрос за 27 реда, от които един празен, събрани на 80 колони (както всеки сорс код следва да бъде). Имайки горното, мога да напиша това:

(let* ((n 100000)
       (a (make-array n)))
  (dotimes* (i n)
    (setf (aref a i) (* 2 i))))

което отговаря на main функцията на C програмата, дадена малко по-горе. Единственото, което съм променил спрямо стандартен Lisp е, че вместо dotimes съм написал dotimes*. Получавам същия ефект като при parallel for конструкцията на OpenMP. Е, не е като да съм направил сайт, документация, нямам борд на директорите на консорциум, нито екип от 100-200 човека, които да направят пачове на всеки известен компилатор, но пък от друга страна...не ми и трябват. В интерес на истината моите 27 реда не могат да се сравняват със софистицизма на OpenMP, но реализират 98% от usage pattern-а му. Представете си какво би могло да се направи с 270 или 2700 реда на Lisp. А за JOMP не искам и да си спомням, защото ще сънувам кошмари (наистина, прочетете описанието, за да го сравните после с 27-те реда).

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