Forth http://fforum.winglion.ru/ |
|
Забеги с участием SPF и других систем на время http://fforum.winglion.ru/viewtopic.php?f=18&t=761 |
Страница 1 из 1 |
Автор: | profiT [ Чт май 24, 2007 17:09 ] |
Заголовок сообщения: | Забеги с участием SPF и других систем на время |
Посмотрел сегодя немножко SwiftForth. Осталась у меня скачанная с их сайта версия, пока вроде денег не требует и работает. Гляжу -- а там сравнение. Дай думаю померяюсь. http://files.myopera.com/profiT/forth/bench.7z Для SPF'а вражеский форт-исходник конечно нужно было слегка подрихтовать, но это было несложно: Код: SPF 4.18 sec ms us ns = Timing for this system 042 = Timing for DO LOOP 000 = Timing for * 014 = Timing for / 001 = Timing for + 006 = Timing for M* 015 = Timing for UM/MOD 010 = Timing for M+ 014 = Timing for /MOD 017 = Timing for */ 954,059 = Timing for Fibonacci recursion ( 24 -> 46368 ) 213,825 = Timing for Eratosthenes sieve 1899 Primes 60,993 = Timing for Hoare's quick sort (reverse order) 271 = Timing for EDN's string comparison Код: SwiftForth 3.03 Evaluation Version
sec ms us ns = Timing for this system 015 = Timing for DO LOOP 001 = Timing for * 016 = Timing for / 000 = Timing for + 005 = Timing for M* 019 = Timing for UM/MOD 012 = Timing for M+ 019 = Timing for /MOD 021 = Timing for */ 915,512 = Timing for Fibonacci recursion ( 24 -> 46368 ) 190,414 = Timing for Eratosthenes sieve 1899 Primes 106,918 = Timing for Hoare's quick sort (reverse order) 253 = Timing for EDN's string comparison Интересно это. Ведь если посмотреть на SwiftForth то он пусть и делает тоже как и SPF компиляцию непосредственно в маш. код и инлайнит тоже, но сверх того он-то больше ничего не делает. А по раскладкам на стек и регистры SwiftForth и SPF практически ведь близнецы-братья -- тоже аппаратный стек как стек возвратов, указатель стека данных в EPB, только регистры TOS разные -- у SPF EAX, у SwiftForth'а EBX. (чтобы это узнать эти подробности архитектуры Swift'а я просто писал: "SEE DUP", "SEE DROP" и так далее).. Теперь мысли по каждому тесту: DO LOOP -- ну что тут сказать?.. SPF за свой "интересный" код DO LOOP заслуженно получил на орехи. Всевозможные умножения и деления -- ну где-то наравне... Всё равно копейкой дороже, копейкой дешевле. Фибоначчи и Эратосфен -- SPF проиграл сколько-то там процентов. Обидно. Вот на быстрой сортировке SPF оторвался. Обратите внимание что это единственный тест, написанный целым лексиконом (там где-то пять слов). Сравнение строк. Ну, тут просто сравнение кто лучше на ассемблере пишет (у обоих систем слово SEARCH написано в кодах). Получается так что Элизабет (E. Rather) пишет лучше. Обратите внимание что SPF'овский SEARCH использует цепочечную инструкцию lods , а Swift'овский не использует. Хотя-хотя, насколько тест показателен, ведь строка для сравнения всё время одна и та же совсем небольшая (хотя по поводу размера спорно что лучше подходит). |
Автор: | chess [ Чт май 24, 2007 17:21 ] |
Заголовок сообщения: | |
profiT писал(а): Фибоначчи и Эратосфен -- SPF проиграл сколько-то там процентов. Обидно.
У SwiftForth в качестве Тос используется EBX, и это, несмотря на несколько более слабый оптимизатор, чем в SPF, дает ему некоторое преимущество (аккумулятор - EAX чаще свободен, чем в SPF). |
Автор: | Mihail [ Чт май 24, 2007 18:01 ] |
Заголовок сообщения: | |
profiT писал(а): DO LOOP -- ну что тут сказать?.. SPF за свой "интересный" код DO LOOP заслуженно получил на орехи.
Кинь сюда результат SEE $DO$ под SwiftForth . (Не хочется возится с установкой SwiftForth) Во всех тестах используется LOOP . Может, все дело в нем. |
Автор: | profiT [ Пт май 25, 2007 09:30 ] |
Заголовок сообщения: | |
Mihail Код: SEE $DO$
46DE3F 46DC6F ( [$ ) CALL E82BFEFFFF 46DE44 40235F ( (DO) ) CALL E81645F9FF 46DE49 4 # EBP SUB 83ED04 46DE4C EBX 0 [EBP] MOV 895D00 46DE4F 0 [ESP] EBX MOV 8B1C24 46DE52 4 [ESP] EBX ADD 035C2404 46DE56 46DCDF ( DROPS ) CALL E884FEFFFF 46DE5B 0 [ESP] INC FF0424 46DE5E 46DE49 JNO 0F81E5FFFFFF 46DE64 8 # ESP ADD 83C408 46DE67 46DD0F ( $] ) CALL E8A3FEFFFF 46DE6C EBX EBX OR 09DB 46DE6E 0 [EBP] EBX MOV 8B5D00 46DE71 4 [EBP] EBP LEA 8D6D04 46DE74 46DE3F JZ 0F84C5FFFFFF 46DE7A 40501F ( (S") ) CALL E8A071F9FF 46DE7F "DO LOOP" 46DE88 4042AF ( TYPE ) JMP E92264F9FF ok |
Автор: | Hishnik [ Сб май 26, 2007 16:43 ] |
Заголовок сообщения: | |
А чего же такие непредставительные тесты? По сути, здесь тестировались не особенности организации транслятора и создаваемого им кода, а квалификация программиста, создававшего ассемблерные определения. Очевидно, что все операции с / займут большее время просто в силу того, что однотактное деление целых чисел - из области научной фантастики (кстати, именно научной, поскольку все же можно). Очевидно также, что циклы тоже будут замедлять работу. А вот качественно иного уровня здесь не видно. Хотя при разработке реальных программ мы все-таки махнем рукой на все ускоряющие хитрости и будет писать так, как удобнее всего для этого транслятора. С соответствующими результатами. |
Автор: | profiT [ Вт сен 11, 2007 18:09 ] |
Заголовок сообщения: | |
--- |
Автор: | Kopa [ Пт сен 14, 2007 09:21 ] |
Заголовок сообщения: | |
profiT писал(а):
Здесь http://shootout.alioth.debian.org/ можно взять исходники этих и других используемых тестов и их сравнение для разных языков:) |
Автор: | Гость [ Вт янв 29, 2008 14:02 ] |
Заголовок сообщения: | |
Хищник писал(а): А чего же такие непредставительные тесты?
Такие уж сложились, как данность от MPE:) Для Swift3.1 (P2.4) Код: Test time including overhead ms times ns (each)
Eratosthenes sieve 1899 Primes 184 8190000 22 Fibonacci recursion ( 35 -> 9227465 ) 197 9227430 21 Hoare's quick sort (reverse order) 202 2000000 101 Generate random numbers (1024 kb array) 226 262144 862 LZ77 Comp. (400 kb Random Data Mem>Mem) 1448 1 Dhrystone (integer) 311 500000 622 1607717 Dhrystones/sec Total: 2572 1 Похоже теже проблемы с кодогенерацией, что и у SPF4 проявились на LZ77 тесте P.S. Проблема при генерации всего в кодофайл: Производительность сильно деградирует, в зависимости от удаленности переменной от места кода её использующего. |
Автор: | Гость [ Вт янв 29, 2008 14:08 ] |
Заголовок сообщения: | |
пример от ~ygrek для spf4. Код: 10000000 VALUE total
400 ( N ) VALUE offset VARIABLE data offset ALLOT : test total 0 DO data @ data ! LOOP ; WINAPI: GetTickCount KERNEL32.DLL : ms@ GetTickCount ; ms@ test ms@ - ABS . В зависимости от значения оffset результаты очень удивительные и не совсем однозначные:) |
Автор: | profiT [ Вт янв 29, 2008 17:30 ] |
Заголовок сообщения: | |
--- |
Автор: | ygrek [ Ср янв 30, 2008 00:11 ] |
Заголовок сообщения: | |
profiT писал(а): Возможное объяснение: Что это обьясняет? Тут ведь выпихивать ничего не надо - всё прекрасно помещается в кэши. Возможная версия (то что я писал в spf-dev) - что при записи например в кэш L1i соответствующий кусок памяти из L1d сбрасывается, потом наоборот и так по кругу - не срабатывает т.к. расстояние слишком большое так что инструкции и данные могли спокойно лежать в разных кэшах не задевая друг-друга. А вот то что в P4 и позднее (новые Celeron'ы тоже с этой "фичей") появился trace-cache, который хранит декодированные микроинструкции, добавляет новое условие - Dmitry Groshev писал(а): запись в память вызывает инвалидацию кэша трассы (trace cache) для всех адресов в радиусе 1 Кб от записанного.
Непонятно почему именно такой большой радиус "поражения". Возможно из-за того что trace кэш хранит логически связанную цепочку микрокодов, которая может быть произвольно длинной? и поэтому надо превентивно сбрасывать её всю полностью. По trace-cache видел работу на citeseer - наверное её и надо штудировать - [url=http://citeseer.ist.psu.edu/rotenberg96trace.html]. Trace Cache: a Low Latency Approach to High Bandwidth Instruction Fetching (1996)[/url] |
Автор: | ygrek [ Ср янв 30, 2008 00:14 ] |
Заголовок сообщения: | |
кстати, этот trace cache полность заменяет L1i |
Автор: | Kopa [ Вс авг 30, 2009 18:34 ] |
Заголовок сообщения: | |
Новость из с.l.f от Anton Ertl Applic ation benchmark suite available Код: ...
ABOUT THE BENCHMARKS Benchmark Author Purpose, Remarks bench-gc 1.0 Anton Ertl Garbage Collector brainless 0.0.2 David Kuehling Chess, different results for 32-bit and 64-bit systems brew 0.2.0 Robert Epprecht Evolutionary playground, incorrect on 64-bit cd16sim v11 Brad Eckert CPU emulator cross 0.7.x Bernd Paysan Forth cross compiler, Gforth only, short run, unstable fcp 1.31-64 Ian Osgood Chess lexex Gerry Jackson Scanner Generator vmgen 0.7.x Anton Ertl Interpreter generator, Gforth-only, short run ... appbench.zip (~1Mb) |
Автор: | Гость [ Вт дек 13, 2011 14:56 ] |
Заголовок сообщения: | Re: Забеги с участием SPF и других систем на время |
Forth83 Benchmarks Забеги с участием разного железа (очень разного) и разных Форт систем на основе Wiki http://theultimatebenchmark.org/ |
Автор: | Alexander [ Пн дек 26, 2011 20:10 ] |
Заголовок сообщения: | Re: Забеги с участием SPF и других систем на время |
Ух... Ну и мои 5 копеек: Желательно при всех тестах указыват размер кэша команд процессора и количество ядер. Правильная взвешенная оценка получается только после того, как тесты выполнены на различных архитектурах. Последний SwiftForth - версии 3.4.1. К сведению, код свифта писала группа разработчиков...читайте комменты в исходниках, если они у вас есть. Доступны версии Свифта для Маков и Линуксов , условия распространения на сайте производителя. |
Страница 1 из 1 | Часовой пояс: UTC + 3 часа [ Летнее время ] |
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group http://www.phpbb.com/ |