_Loader_

Hi Eugene,

Tue Sep 30 2003 17:44, Eugene Romanov wrote to Alex Kouznetsov:

AK>>>> Скорость зависит от того как сделан интерпретатор. PU>>> Hо она никогда не переплюнет скорость работы native кода?! Ж8-) AK>> Встречались сообщения, что вполне может переплюнуть, AK>>

Чтобы было понятнее, SPF4 - AK>> это Форт с оптимизацией.

ER> Меня теpзают cмyтные cомнения, что это пpоcто иcходный алгоpитм ER> cоптимизиpовалcя гpамотно. А до нативного кода любомy интеpпpетатоpy - ER> как до Лyны пешком. Ибо на какой-нибyдь "add r0, #15" нативного кода ER> бyдет навешано некотоpое количеcтво телодвижений интеpпpетатоpа.

Это распространенное мнение, но вообще-то оно ошибочно. То есть, для большинства интерпретаторов это так. Но не для всех. Граница между интерпретацией и исполнением нативного кода весьма зыбка и расплывчата, особенно если имеешь дело с Фортом. SPF, о котором идет речь, использует так наз. подпрограммный шитый код. Программа, интерпретируемая им, выглядит примерно так: call DUP call MUL ... и т.д. Так что из "телодвижений интеpпpетатоpа" на каждое слово приходятся только call и ret. "Внутренности" SPF я знаю не очень хорошо, но по-моему при трансляции он инлайнит некоторую часть кода (по крайней мере, литералы и переходы). Если сравнивать это с результатом работы какого-нибудь С компилятора, то особо большой разницы не заметишь. Разве что больше call-ов, и нет манипуляций с фреймами.

Пока, Алексей

Hi Eugene,

Wed Oct 01 2003 15:30, Eugene Romanov wrote to Alex Kouznetsov:

AK>> Это распространенное мнение, но вообще-то оно ошибочно. То есть, для AK>> большинства интерпретаторов это так. Hо не для всех. Граница между AK>> интерпретацией и исполнением нативного кода весьма зыбка и AK>> расплывчата, особенно если имеешь дело с Фортом.

AK>> SPF, о котором идет речь, использует так наз. подпрограммный шитый AK>> код. Программа, интерпретируемая им, выглядит примерно так: AK>> call DUP AK>> call MUL

ER> Эти "call" - команды пpоцеccоpа или виpтyальной фоpт-машины? Еcли ER> пpоцеccоpа, то мы имеем дело c компилиpованной в нативный код пpогpаммой. ER> Далее идет пpоcто cpавнение качеcтва компилятоpов.

Это команды процессора. Я же писал, граница между нативным кодом и нинтерпретируемым очень зыбкая. Для подпрограммного шитого кода "интерпретатор" - это сам процессор, с его call и ret, а вся Форт-система может быть представлена как определенным образом организованный набор подпрограмм. Тем не менее, Форт традиционно считается интерпретируемым языком.

Изначально ведь речь шла о том, насколько быстрым может быть интерпретатор. Я привел пример - практически он может быть сколь угодно быстрым.

Пока, Алексей

30-Sep-03 16:44 Eugene Romanov wrote to Alex Kouznetsov:

AK>>>> Скорость зависит от того как сделан интерпретатор. PU>>> Hо она никогда не переплюнет скорость работы native кода?! Ж8-) AK>> Встречались сообщения, что вполне может переплюнуть, AK>>

Чтобы было понятнее, SPF4 - AK>> это Форт с оптимизацией.

ER> Меня теpзают cмyтные cомнения, что это пpоcто иcходный алгоpитм ER> cоптимизиpовалcя гpамотно. А до нативного кода любомy интеpпpетатоpy - ER> как до ER> Лyны пешком. Ибо на какой-нибyдь "add r0, #15" нативного кода бyдет ER> навешано ER> некотоpое количеcтво телодвижений интеpпpетатоpа. А напиcать нативный Да нет. Форт с оптимизацией "разворачивает" слова в машкод. Пользуясь С-шной терминологией, "инлайнит" все функции и дальше оптимизирует машкод. Но тут два момента:

1) тут уже надо "помахать ручкой" компактности кода, присущей интерпретаторам. Адепты форта обычно "забывают" об этом, и умудряются одновремённо говорить "самый компактный" и "самый быстрый". Думаю, впрочем, что они такие же фортеры, как "линуксоиды", которые только и умеют кричать Win must die, а сами линукса не знают.

2) Я согласен, что такой оптимизированный код может быть быстрее, чем программа, сгенерённая плохим C-компилятором или написанная плохим ASM-программистом. Но те же адепты почему-то об этом ("плохим") тоже забывают.

Ну и в любом случае - какой бы оптимизирующий форт мы не взяли, если форт-программу ему на вход писал плохой фортер, то он (опт.форт) её не вытянет. А все мы знаем, что при большом желании сравнить тайд с "другим порошком" можно так, что станет странно, почему производители "другого порошка" ещё не повесились.

wbr,

Hi Oleksandr,

Wed Oct 01 2003 22:20, Oleksandr Redchuk wrote to Eugene Romanov:

AK>>>>> Скорость зависит от того как сделан интерпретатор. PU>>>> Hо она никогда не переплюнет скорость работы native кода?! Ж8-) AK>>> Встречались сообщения, что вполне может переплюнуть, AK>>>

Чтобы было понятнее, SPF4 - AK>>> это Форт с оптимизацией.

ER>> Меня теpзают cмyтные cомнения, что это пpоcто иcходный алгоpитм ER>> cоптимизиpовалcя гpамотно. А до нативного кода любомy интеpпpетатоpy - ER>> как до ER>> Лyны пешком. Ибо на какой-нибyдь "add r0, #15" нативного кода бyдет ER>> навешано ER>> некотоpое количеcтво телодвижений интеpпpетатоpа. А напиcать нативный

OR> Да нет. OR> Форт с оптимизацией "разворачивает" слова в машкод. OR> Пользуясь С-шной терминологией, "инлайнит" все функции и дальше OR> оптимизирует машкод.

Нет, насколько мне известно, именно так никто не делает. Тела функций (Форт-слов) не инлайнятся, для подпрограммного шитого кода они остаются быть подпрограммами. Инлайнятся более мелкие элементы, как то литералы, переходы и возвраты. Оптимизация при (любой, не только в Фортах) трансляции осуществляется гораздо раньше, еще до того как получился исполняемый код. Машкод всерьез никто не оптимизирует, т.к. геморроя не оберешься, а результаты мизерные. Неэффективно.

Пока, Алексей

Hi Eugene,

Thu Oct 02 2003 10:02, Eugene Romanov wrote to Oleksandr Redchuk:

ER> Только это yже cкоpее компилятоp полyчаетcя, pаз на выходе нативщина ER> cплошная.

Для информациии: в состав Форта обычно входят два интерпретатора ("наружный" и "внутренний") и компилятор. В большинстве современных интерпретирующих систем исходник сначала компилируется. Интерпретируется же байт-код, т.е. скомпилированный код. Форт в этом смысле не исключение, просто у него все в одном флаконе, и компилятор, и интерпретатор(ы). Кстати, его компилятор исполняется, ессно, путем интерпретации ;-)

OR>> Hу и в любом случае - какой бы оптимизирующий форт мы не OR>> взяли, если форт-программу ему на вход писал плохой фортер, то он OR>> (опт.форт) её не вытянет. А все мы знаем, что при большом желании OR>> сравнить тайд с "другим порошком" можно так, что станет странно, OR>> почему производители "другого порошка" ещё не повесились.

ER> Во-во. Или еcли алгоpитм выбpан бyдет неyдачный. ER> Кcтати, на этy темy: "да мой интеpпpетатоp pвет аccемблеp по cкоpоcти" за ER> поcледний год yже доводилоcь cпоpить. В оффлайне. И как ни cтpанно - c ER> фоpтеpом же. Похоже, очеpедная "cвященная война" гpядет.

Хм... Тогда начнем, пожалуй ;-) Значит, то что проги, скомпилированные O'Caml или VC7, оказались быстрее ассемблерной - никого не удивило? Это показалось правдоподобным? А то что Форт "втиснулся" между - все сразу заворчали, что этого не может быть, поскольку "быстрей ассемблера не напишешь"? Смешная логика...

Пока, Алексей

2-Oct-03 09:48 Alex Kouznetsov wrote to Eugene Romanov:

AK> Хм... Тогда начнем, пожалуй ;-) AK> Значит, то что проги, скомпилированные O'Caml или VC7, оказались быстрее AK> ассемблерной - никого не удивило? Это показалось правдоподобным? А то Насколько я помню, там напротив ассемблера было написано что-то в духе "особо не оптимизируя".

AK> что Форт AK> "втиснулся" между - все сразу заворчали, что этого не может быть, AK> поскольку "быстрей ассемблера не напишешь"? Смешная логика... Это отдельнй разговор. "Это" - это то, что для современных процессоров с несколькими исп. устройствами, переименованием регистров, out of order исполнением и т.п. на асме ручками тяжело всё учесть и _хороший_ компилятор ЯВУ уделывает среднего программиста на асме -- это понятно всем, кроме тех ассемблерррррррщиков, котороые ведут себя как форррррррррррррррртеры (не путать с фортерами :-) и в качестве примера берут какой-нибудь зачуханный C-компилятор против кода, долго лизанного хорошими ассемблерщиками. Но про ЯВУ такое начали говорить совсем недавно, именно когда процессоры стали слишком умными. А вот то, что форт-программы быстрее ассемблерных -- я лично слышу со времён 80386. И сейчас -- зачастую без уточнения процессора. Я ещё не слышал, что после хорошего С-компилятора программа для AVR|MCS51|PIC|MSP430 работает быстрее, чем написанная на ассемблере. Про форт такое слышал. Впрочем, заодно с тем, что "у него ядро 17 байт, а вот у С!!!!" Поэтому ссылки на O'Caml и VC7 в данном случае не канают, давай ограничимся PIC*|AVR|MCS51|MSP430|...ну давай ARM7 и повторим эксперимент. И неплохо бы не только на функции Аккермана, а на чём-нибудь менее рекурсивном и более применимом в эхотаге, скажем, FIR, CRC16, подстановка байтов SLIP или PPP, ...

wbr,

Fri Oct 03 2003 00:05, Oleksandr Redchuk wrote to "Alex Kouznetsov":

OR> "Это" - это то, что для современных процессоров с несколькими исп. OR> устройствами, переименованием регистров, out of order исполнением и т.п. OR> на асме ручками тяжело всё учесть и _хороший_ компилятор ЯВУ уделывает OR> среднего программиста на асме -- это понятно всем, кроме тех

Ага... именно так. Написать на асме программу даже для первого пентиума с двумя конвейерами, учитывая порядок выполнения, возможность спаривания и т.п.

- уже нетривиальная задача. К тому же при работе на ассемблере вне пределов вылизываемой вставки кода бывает трудно отследить использование регистров и не скатиться к обычному load/store стилю.

OR> ассемблерррррррщиков, котороые ведут себя как форррррррррррррррртеры OR> (не путать с фортерами :-) и в качестве примера берут какой-нибудь OR> зачуханный C-компилятор против кода, долго лизанного хорошими OR> ассемблерщиками.

Ну это фанатство... оно что в Африке фанатство, что в среде фортеров (линуксоидов, сишников и т.д.....)

OR> Hо про ЯВУ такое начали говорить совсем недавно, именно когда процессоры OR> стали слишком умными. А вот то, что форт-программы быстрее ассемблерных OR> -- я лично слышу со времён 80386. И сейчас -- зачастую без уточнения OR> процессора. OR> Я ещё не слышал, что после хорошего С-компилятора программа для OR> AVR|MCS51|PIC|MSP430 работает быстрее, чем написанная на ассемблере. OR> Про форт такое слышал. Впрочем, заодно с тем, что "у него ядро 17 байт, OR> а вот у С!!!!"

Это тоже фанатство. После "усредненного" Форта получается все же чуть медленнее, хотя бы накладные расходы на вызовы слов (call/ret) и стековые манипуляции. Конечно, можно это убрать оптимизацией... но закавыка в том, что такая оптимизация не есть неотъемлемое свойство именно Форта.

OR> Поэтому ссылки на O'Caml и VC7 в данном случае не канают, OR> давай ограничимся PIC*|AVR|MCS51|MSP430|...ну давай ARM7 и повторим OR> эксперимент. И неплохо бы не только на функции Аккермана, а на чём-нибудь OR> менее рекурсивном и более применимом в эхотаге, скажем, FIR, CRC16, OR> подстановка байтов SLIP или PPP, ...

Если в лоб, то естественно, Форт будет медленнее. Хотя я недавно на 8 МГц форт-процессоре с треском обогнал MB90F549. 5 сек против 3,5 мин. И загадки никакой нет - шла работа с 96-битными числами, которые на MB90 считались ... ну понятно как считались, с битом переноса. А в Форт-процессор был встроен

96-битный арифметический блок... :)))) Пояснение смахивает на шутку, но в действительности Форт здесь выступил в своей обычной роли - не так сложно в реализации, как Си (или процессоры "общего назначения"), с другой стороны, работа уже не на уровне машинного кода. Обвязать 96-битный арифметический блок приемлемой по удобству дальнейшей работы логикой (речь о внутренностях ПЛИС) - очень непросто. Привязать этот блок к софтовому ядру форт-процессора - уже можно, причем сразу получается "чуть больше, чем ассемблер".