OberonCore

O_O

спасибо вам, великие Боги Электричества, за то, что помешали мне заняться вытаскиванием его в стандалон-систему. узнавание сего факта после было бы моим личным разочарованием века. я-то — глядя на его жирность — думал что он… а он… эх! (гифка с машущим рукой Тиллем)

так и в компиляторе от бб тоже ее нет. а примитивная и в фоксе есть, но я это не считаю.

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

я, конечно, это не в претензию: нет — и нет, CP2 вон и так нормально справляется. жаль просто, что нет — украсть негде. ;-)

Fox и разрабатывался стприцелом на ssa - архитектура так выстроена. Нот модуля ssa в репозитории нет.

хучь срочно допиливай нужные части OberonJIT, чтобы погонять.

алсо, посмотрел на код — а ему реально надо так адово аллокатить? это уже чуть ли не тест GC получается.

Во-первых, см. приписку про пианиста. Я ни в коем случае не программист и не претендую. Во-вторых, формально, несмотря на неоптимальность реализации, тут наблюдается соответствие заявленной теме


В-третьих, буду рад конструктивным предложениям. Правда, они будут выходом за рамки темы.

Хм. Я, оказывается, неправильно использовал Джулию. Переделал реализацию, спрятав всю программу из глобальной области в функцию run(). Загрузил программу через include в интерпретаторе. Запустил оттуда функцию run(). Замерил скорость работы на втором пуске (в течение первого пуска идёт компиляция). Теперь Джулия намного опережает все остальные реализации

я код не анализировал, просто быстроглянул — и увидел локальные аллокаторы. в большинстве случаев это значит, что память разбрасывают как отряд сеятелей. NEW очень дешёвый, GC очень дорогой.

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

это одна из причин, по которым я считаю бенчмарки бесполезными, кстати: в большинстве случаев пишется некий «общий» код, который очень плохо заточен под конкретную среду/язык. в итоге выигрывает обычно та, для которой код наиболее «идиоматичен» и попадает в нужные паттерны оптимизации. то есть, бенчмарк говорит, насколько плохо нечто справляется с плохим кодом. как по мне — не самая полезная информация. ;-)

это всё не в упрёк автору темы, прошу прощения. просто бурчу.

по ходу, всё это можно ускорить минимум в два раза, если использовать статические массивы, а не динамические. с динамическми у меня BBCB отрабатывает за ~30 секунд, а со статическими — за ~13. только не забыть IN/VAR/OUT порасставлять где надо, чтобы лишних копирований не было.

p.s.: замечу касательно темы: оберон не пытается умничать. предполагается, что алгоритм оптимизирует программист, а компилятор поёт то, что ему дали. не пытаясь проводить какие-то трансформации кода сложнее constant folding. с одной стороны это требует больше усилий для написания эффективного кода, зато с другой — компилятор очень быстрый (что важно в итеративном подходе), и можно быть более-менее уверенным, что он (компилятор) не перепишет валидный код в какой-то бред, потому что кто-то где-то решил, что так можно. (привет, сишечка-со-стандартами!) вот мы разгрузили GC и убрали бесконечные проверки на NIL — и код сразу ускорился в два раза вообще без изменения алгоритмов.

кстати, на оригинальном BBCB со статическими массивами ещё быстрее будет. я-то проверял на LC, а там у меня включено насильственное зануление всех локалов, включая массивы без указателей. в оригинале эта опция выключена, так что будет секунды на полторы-две быстрей, думаю.