Автор |
Сообщение |
|
|
Заголовок сообщения: |
Re: Забеги с участием SPF и других систем на время |
|
|
Ух... Ну и мои 5 копеек: Желательно при всех тестах указыват размер кэша команд процессора и количество ядер. Правильная взвешенная оценка получается только после того, как тесты выполнены на различных архитектурах. Последний SwiftForth - версии 3.4.1. К сведению, код свифта писала группа разработчиков...читайте комменты в исходниках, если они у вас есть. Доступны версии Свифта для Маков и Линуксов , условия распространения на сайте производителя.
Ух... Ну и мои 5 копеек: Желательно при всех тестах указыват размер кэша команд процессора и количество ядер. Правильная взвешенная оценка получается только после того, как тесты выполнены на различных архитектурах. Последний SwiftForth - версии 3.4.1. К сведению, код свифта писала группа разработчиков...читайте комменты в исходниках, если они у вас есть. Доступны версии Свифта для Маков и Линуксов , условия распространения на сайте производителя.
|
|
|
|
Добавлено: Пн дек 26, 2011 20:10 |
|
|
|
|
|
Заголовок сообщения: |
Re: Забеги с участием SPF и других систем на время |
|
|
Forth83 Benchmarks Забеги с участием разного железа (очень разного) и разных Форт систем на основе Wiki http://theultimatebenchmark.org/
Forth83 Benchmarks Забеги с участием разного железа (очень разного) и разных Форт систем на основе Wiki [url]http://theultimatebenchmark.org/[/url]
|
|
|
|
Добавлено: Вт дек 13, 2011 14:56 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
Новость из с.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)
Новость из с.l.f от Anton Ertl
[url=http://groups.google.com/group/comp.lang.forth/browse_thread/thread/f9a14ef8a6a618c9#]Applic ation benchmark suite available[/url]
[code] ... 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 ... [/code]
[url=http://www.complang.tuwien.ac.at/forth/appbench.zip]appbench.zip (~1Mb)[/url]
|
|
|
|
Добавлено: Вс авг 30, 2009 18:34 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
кстати, этот trace cache полность заменяет L1i
кстати, этот trace cache полность заменяет L1i
|
|
|
|
Добавлено: Ср янв 30, 2008 00:14 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
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]
[quote="profiT"]Возможное объяснение:[/quote] Что это обьясняет? Тут ведь выпихивать ничего не надо - всё прекрасно помещается в кэши. Возможная версия (то что я писал в spf-dev) - что при записи например в кэш L1i соответствующий кусок памяти из L1d сбрасывается, потом наоборот и так по кругу - не срабатывает т.к. расстояние слишком большое так что инструкции и данные могли спокойно лежать в разных кэшах не задевая друг-друга. А вот то что в P4 и позднее (новые Celeron'ы тоже с этой "фичей") появился trace-cache, который хранит декодированные микроинструкции, добавляет новое условие - [quote="Dmitry Groshev"] запись в память вызывает инвалидацию кэша трассы (trace cache) для всех адресов в радиусе 1 Кб от записанного. [/quote]
Непонятно почему именно такой большой радиус "поражения". Возможно из-за того что 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]
|
|
|
|
Добавлено: Ср янв 30, 2008 00:11 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
|
|
|
Добавлено: Вт янв 29, 2008 17:30 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
пример от ~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 результаты очень удивительные
и не совсем однозначные:)
пример от ~ygrek для spf4.
[code] 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 . [/code]
В зависимости от значения оffset результаты очень удивительные
и не совсем однозначные:)
|
|
|
|
Добавлено: Вт янв 29, 2008 14:08 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
Хищник писал(а): А чего же такие непредставительные тесты?
Такие уж сложились, как данность от 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. Проблема при генерации всего в кодофайл:
Производительность сильно деградирует, в зависимости от удаленности переменной
от места кода её использующего.
[quote="Хищник"]А чего же такие непредставительные тесты? [/quote]
Такие уж сложились, как данность от MPE:)
Для Swift3.1 (P2.4)
[code] 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 [/code]
Похоже теже проблемы с кодогенерацией, что и у SPF4 проявились на LZ77 тесте
P.S. Проблема при генерации всего в кодофайл:
Производительность сильно деградирует, в зависимости от удаленности переменной
от места кода её использующего.:)
|
|
|
|
Добавлено: Вт янв 29, 2008 14:02 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
profiT писал(а): Re: [Spf-dev] BENCHMARK"Andrey Filatkin" Thu, 18 Apr 2002
Здесь
http://shootout.alioth.debian.org/
можно взять исходники этих и других используемых тестов и их сравнение для разных языков:)
[quote="profiT"][url=http://www.nabble.com/Re%3A-BENCHMARK-tf4335607.html#a12347979]Re: [Spf-dev] BENCHMARK[/url] "Andrey Filatkin" Thu, 18 Apr 2002 [/quote]
Здесь
http://shootout.alioth.debian.org/
можно взять исходники этих и других используемых тестов и их сравнение для разных языков:)
|
|
|
|
Добавлено: Пт сен 14, 2007 09:21 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
|
|
|
Добавлено: Вт сен 11, 2007 18:09 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
А чего же такие непредставительные тесты? По сути, здесь тестировались не особенности организации транслятора и создаваемого им кода, а квалификация программиста, создававшего ассемблерные определения. Очевидно, что все операции с / займут большее время просто в силу того, что однотактное деление целых чисел - из области научной фантастики (кстати, именно научной, поскольку все же можно). Очевидно также, что циклы тоже будут замедлять работу. А вот качественно иного уровня здесь не видно. Хотя при разработке реальных программ мы все-таки махнем рукой на все ускоряющие хитрости и будет писать так, как удобнее всего для этого транслятора. С соответствующими результатами.
А чего же такие непредставительные тесты? По сути, здесь тестировались не особенности организации транслятора и создаваемого им кода, а квалификация программиста, создававшего ассемблерные определения. Очевидно, что все операции с / займут большее время просто в силу того, что однотактное деление целых чисел - из области научной фантастики (кстати, именно научной, поскольку все же можно). Очевидно также, что циклы тоже будут замедлять работу. А вот качественно иного уровня здесь не видно. Хотя при разработке реальных программ мы все-таки махнем рукой на все ускоряющие хитрости и будет писать так, как удобнее всего [b]для этого транслятора[/b]. С соответствующими результатами.
|
|
|
|
Добавлено: Сб май 26, 2007 16:43 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
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
[b]Mihail[/b]
[code] 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 [/code]
|
|
|
|
Добавлено: Пт май 25, 2007 09:30 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
profiT писал(а): DO LOOP -- ну что тут сказать?.. SPF за свой "интересный" код DO LOOP заслуженно получил на орехи.
Кинь сюда результат SEE $DO$ под SwiftForth . (Не хочется возится с
установкой SwiftForth)
Во всех тестах используется LOOP . Может, все дело в нем.
[quote="profiT"]DO LOOP -- ну что тут сказать?.. SPF за свой "интересный" код DO LOOP заслуженно получил на орехи.[/quote]
Кинь сюда результат SEE $DO$ под SwiftForth . (Не хочется возится с
установкой SwiftForth)
Во всех тестах используется LOOP . Может, все дело в нем.
|
|
|
|
Добавлено: Чт май 24, 2007 18:01 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
profiT писал(а): Фибоначчи и Эратосфен -- SPF проиграл сколько-то там процентов. Обидно.
У SwiftForth в качестве Тос используется EBX, и это, несмотря на несколько более слабый оптимизатор, чем в SPF,
дает ему некоторое преимущество (аккумулятор - EAX чаще свободен, чем в SPF).
[quote="profiT"]Фибоначчи и Эратосфен -- SPF проиграл сколько-то там процентов. Обидно. [/quote]
У SwiftForth в качестве Тос используется EBX, и это, несмотря на несколько более слабый оптимизатор, чем в SPF,
дает ему некоторое преимущество (аккумулятор - EAX чаще свободен, чем в SPF).
|
|
|
|
Добавлено: Чт май 24, 2007 17:21 |
|
|
|
|
|
Заголовок сообщения: |
Забеги с участием 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'овский не использует. Хотя-хотя, насколько тест показателен, ведь строка для сравнения всё время одна и та же совсем небольшая (хотя по поводу размера спорно что лучше подходит).
Посмотрел сегодя немножко SwiftForth. Осталась у меня скачанная с [url=http://forth.com]их сайта[/url] версия, пока вроде денег не требует и работает. Гляжу -- а там сравнение. Дай думаю померяюсь.
http://files.myopera.com/profiT/forth/bench.7z
Для SPF'а вражеский форт-исходник конечно нужно было слегка подрихтовать, но это было несложно:
[code] 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 [/code]
[code] 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 [/code]
Интересно это. Ведь если посмотреть на 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'овский не использует. Хотя-хотя, насколько тест показателен, ведь строка для сравнения всё время одна и та же совсем небольшая (хотя по поводу размера спорно что лучше подходит).
|
|
|
|
Добавлено: Чт май 24, 2007 17:09 |
|
|
|
|