Тест быстроты сгенерированного кода

@Замабувараев · Регистрация: 18.12.2014

Студворк — интернет-сервис помощи студентам

Синтетический тест быстроты сгенерированного кода разных компиляторов на основе алгоритма быстрой сортировки.

## Требования

1. Алгоритм быстрой сортировки (сортировка Хоара с разбиением по Хоару).
2. Сортировка по возрастанию: от маленького значения к большему.
3. Посторонние библиотеки для сортировки не использовать.
4. Сортировка в одном потоке.

### Измерения

1. Измеряется время сортировки массива.
2. Десять циклов измерений времени, выводится среднее.

### Данные

1. Длина массива 50000000 (пятьдесят миллионов).
2. Тип данных массива: структура из двух полей типа Double: {LowPart, HighPart}.
3. На каждом цикле массив заполняется случайными значениями в интервале `[0, 1)`.
4. Генератор случайных чисел инициализируется заново перед каждым заполнением массива.
5. Количество рекурсивных вызовов функции сотировки должно быть одинаковым на одном и том же наборе данных.
6. Затравка для генератора случайных чисел равна нулю.
7. Функция сравнения переменных a и b (возможна оптимизация):

```
(a.HighPart < b.HighPart) Or ((a.HighPart = b.HighPart) And (a.LowPart < b.LowPart))
```

### Вывод

1. Время выполнения сортировки по каждому циклу.
2. Количество рекурсивных вызовов сортировки (должно быть одинаковым).
3. Среднее время.

Для компиляции этой программы необходим gcc (для "-gen gcc" на x86) и mingw (для утилиты mingw32-make). Необходимые пути к компилятору и утилитам указаны в пакетных файлах.

В результате:

FreeBASIC с задником GCC 5.2.0: среднее время 12080 миллисекунд.
FreeBASIC с задником GCC 8.1.0: среднее время 12445 миллисекунд.
FreeBASIC с задником GCC 10.2.0: среднее время 10993 миллисекунд.

Забавно, что звучащая фоном музыка может замедлять задачу на 1000 миллисекунд.

Приглашаю вступить в игру пропагандистам других диалектов бесика.

@locm · 20.05.2021, 14:11

Я думаю что речь идет о изменении существующего транслятора. Вероятно было проще переписать транслятор из асм в Си чем в LLVM.

@Замабувараев · 20.05.2021, 16:17 **[ТС]**

Сообщение от locm

PB с трансляцией в Си выдал аналогичный результат что и FB.

У вас внутри исполняемых файлов из‐под GCC встречается фраза «GCC: (x86_64-posix-seh-rev0, Built by MinGW-W64 project) 8.1.0». Рекомендую добавить в компоновщик опцию «--gc-sections» чтобы оно не попадало в исполняемый файл.
Ещё можно в GCC отправить «-fdata-sections -ffunction-sections», если ничего большого нет в секции .bss.

Добавлено через 1 час 55 минут

Сообщение от locm

PB с трансляцией в Си выдал аналогичный результат что и FB.

А покажите промежуточный Си‐код который генерирует PureBasic, очень интересно.

@locm · 20.05.2021, 23:06

Код пока неидеальный, но это версия альфа 1, т. е. даже не бета. В дальнейшем наверняка код станет намного лучше.

@Quiet Snow · 20.05.2021, 23:20

Боже как мне не нравится вот эта вся херня, разбивать диалект по кускам и таскать ещё тысячи говнофайлов.
Всё и на PB и на FB было прекрасно и тут начинается это, там быстрее тут быстрее.
Да насрать просто. Лишняя возня и гемор.

@locm · 20.05.2021, 23:37

Сообщение от Quiet Snow

Всё и на PB и на FB было прекрасно и тут начинается это, там быстрее тут быстрее.

Дело не в скорости, а в платформозависимости асма.
Вот что побудило Фреда (разработчика PB) написать транслятор в Си https://www.purebasic.fr/blog/?p=480

Перевод гугла

PureBasic и увеличенные разновидности CPU

Ранние версии PureBasic стартовали на Amiga с поддержкой серии ЦП Motorola 680 × 0. PureBasic был разработан с самого начала для генерации необработанного кода сборки, и первая рабочая внутренняя часть сборки ЦП была для 680 × 0. Поскольку аудитория Amiga быстро уменьшалась, мы решили перейти на ПК. В 1998 году была только одна архитектура ЦП ПК, x86, и было решено добавить для нее новую сборку back-end. Это очень трудоемкая задача и требует большого обучения, чтобы справиться с новой сборкой. Архитектуры 680 × 0 и x86 совершенно противоположны, но они вписались в архитектуру PureBasic, и PureBasic для x86 стал реальностью.

Вскоре после этого мы решили пойти по-настоящему кроссплатформенным и поддержать OS X, работающую на процессорах PowerPC. Нужна была новая сборочная серверная часть, и мы делали это снова в течение почти целого года, чтобы что-то заработало. Вскоре после этого Apple объявила, что откажется от поддержки PowerPC и выберет x86! Для нас это был огромный удар и потрачено много времени. Тем временем был выпущен x86-64, который постепенно набирал обороты, и мы знали, что должны поддерживать и его. В отличие от названия, x86 и x86-64 - два разных зверя, и для этого потребовалось много работы. После этого мы, наконец, могли на некоторое время сосредоточиться на функциональных возможностях, но информатика развивается быстрыми темпами, и появилась новая архитектура ЦП, которая покорила мир, сначала на мобильных устройствах, затем на крошечных компьютерах, а теперь и на настольных компьютерах: ARM и ARM-64.

Итак, чтобы поддержать эти новые платформы, мы снова сталкиваемся с той же проблемой: нам нужны новые серверные части сборки. Как небольшая компания, мы не можем посвящать целый год каждой новой сборке, поэтому нам нужно найти решение, соответствующее требованиям завтрашнего дня. Между тем, был создан форк компилятора PureBasic для генерации языка высокого уровня вместо необработанной сборки. Это позволило создать SpiderBasic, язык, подобный PureBasic, который может работать в браузере путем генерации кода JavaScript.

Когда Apple объявила, что их новые компьютеры будут работать на ARM, мы знали, что нам нужно изменить способ работы с новой архитектурой процессоров, и мы решили использовать уже проделанную работу над SpiderBasic и перенести ее обратно на PureBasic. Мы довольно долго экспериментировали с LLVM, но найти его на всех архитектурах - головная боль. Кроме того, это своего рода смесь ассемблерного кода и языка высокого уровня, поэтому он не подходил ни для PureBasic, ни для внутренней архитектуры SpiderBasic. В течение последних 8 месяцев мы решили сосредоточиться на новом высокоуровневом сервере PureBasic: языке C.

Если в двух словах, Фреду надоело писать транслятор под асм множества процессоров и он посчитал что транслятор в Си будет проще и универсальнее.

@Quiet Snow · 21.05.2021, 00:37

Сообщение от locm

Если в двух словах, Фреду надоело писать транслятор под асм множества процессоров и он посчитал что транслятор в Си будет проще и универсальнее.

Со стороны разработчика выглядит как спихивание с себя ответственности, которой и так не особо
много было(FASM то чужой). Короче ясно, ARM они захотели, денег с эпловодов. Лёгкой наживы.
Подвязав себя, прогнулись под чужое решение. Посмотрим как у них это получится.

@Quiet Snow · 21.05.2021, 01:23

Короче держите резы. Ryzen 3900X
Просто откомпилировал версией (FreeBASIC Compiler - Version 1.07.2 (2020-12-25), built for win32 (32bit))
В кастомный кусорт вникать не буду, нафиг надо.

@Pro_grammer · 21.05.2021, 07:08

Сообщение от Quiet Snow

Всё и на PB и на FB было прекрасно и тут начинается это, там быстрее тут быстрее.
Да насрать просто. Лишняя возня и гемор.

Ну не скажи, уважаемый Quiet Snow! Оптимизация сильная штука.
Вот у тебя один только процессор в общем дороже всего моего компа, и в частности моего процессора примерно в 7 раз

Не оптимизированная версия программы у тебя отработала в среднем за 14.6 сек.
Оптимизированная версия на моём компе отработала за 8.9 сек., на ~ 35% быстрее.

Вот и думай, почему для современных программ людям навязывают такие компы как у тебя, хотя если бы всё оптимизировать и вылизать до байта, как ты любишь, то хватило бы такого компа, как у меня, и ещё бы на 30 % быстрее работало!

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

@Замабувараев · 21.05.2021, 10:06 **[ТС]**

Сообщение от locm

В дальнейшем наверняка код станет намного лучше.

Смотрю на промежуточный код от FreeBASIC, вижу отличия. Вот как делает это FreeBASIC:

* сохраняются отступы;
* много пустых меток;
* нет подавления предупреждений;

* встроенные типы данных транслируются в псевдонимы с чётким указанием разрядности и знаковости;
* все используемые в файле типы данных объявляются в этом же файле;
* структуры объявляются без псевдонима и используются в тексте без псевдонима;
* имена функций переводятся в верхний регистр (если не было модификатора Alias);
* имена переменных переводятся в верхний регистр и добавляется суффикс $ с цифрой;
* операторы и функции‐члены декорируются по правилам, стремящимся к совместимости с C++;

* переменные объявляются не в начале функции, а в месте кода где они объявлены по тексту программы;
* переменные из текста объявляются без инициализирующего значения, инициализирующее значение присваивается переменной на следующей строке;
* результат вызова функций сначала записывается во временную переменную, затем значение временной переменной сохраняется в настоящей переменной;

* встроенные дефиниции компиляции транслируются в константы и литералы, а не переменные;
* использует встроенные функции типа __builtin_memcpy, __builtin_memset и подобные;

* нет индексации по указателю для полей структур, вместо этого указатель приводится к uint8*, прибавляется смещение в байтах и результат приводится обратно к типу данных;
* для указателей ставит звёздочку рядом с типом данных, но это неправильно, звёздочку необходимо ставить рядом с именем переменной;
* не добавляет __stdcall для функций на x64;
* на x64 у числовых литералов всегда есть префикс типа данных;
* строковые литералы записываются не как массив кодов символов, а как текст в кавычках "text literal", к широким литералам добавляется приставка L"text literal";

* все циклы редуцируются до переходов GOTO по метке с проверкой условия;
* условные операторы типа «не равно», «больше», «меньше» могут быть инвертированы, и тела условий переставлены местами;

Добавлено через 8 минут
Вот модифицированный код быстрой сортировки. Он работает с той же скоростью, однако выглядит понятнее и соответствует коду из Педивикии:

PureBasic
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
Type LARGE_DOUBLE
    LowPart AS Double
    HighPart AS Double
End Type
 
Declare Operator < (ByRef lhs As LARGE_DOUBLE, ByRef rhs As LARGE_DOUBLE)As Boolean
 
Declare Operator > (ByRef lhs As LARGE_DOUBLE, ByRef rhs As LARGE_DOUBLE)As Boolean
 
Declare Function QuickSort( _
    ByVal pVector As LARGE_DOUBLE Ptr, _
    ByVal LeftBound As UInteger, _
    ByVal RightBound As UInteger _
)As UInteger
 
Operator < (ByRef lhs As LARGE_DOUBLE, ByRef rhs As LARGE_DOUBLE)As Boolean
    
    If lhs.HighPart < rhs.HighPart Then
        Return True
    End If
    
    If lhs.HighPart = rhs.HighPart Then
        If lhs.LowPart < rhs.LowPart Then
            Return True
        End If
    End If
    
    Return False
    
End Operator
 
Operator > (ByRef lhs As LARGE_DOUBLE, ByRef rhs As LARGE_DOUBLE)As Boolean
    
    If lhs.HighPart > rhs.HighPart Then
        Return True
    End If
    
    If lhs.HighPart = rhs.HighPart Then
        If lhs.LowPart > rhs.LowPart Then
            Return True
        End If
    End If
    
    Return False
    
End Operator
 
Function Partition( _
        ByVal pVector As LARGE_DOUBLE Ptr, _
        ByVal LeftBound As UInteger, _
        ByVal RightBound As UInteger _
    )As UInteger
    
    Dim Pivot As LARGE_DOUBLE = pVector[(LeftBound + RightBound) \ 2]
    
    Dim i As UInteger = LeftBound
    Dim j As UInteger = RightBound
    
    Do
        Do While pVector[i] < Pivot
            i += 1
        Loop
        
        Do While pVector[j] > Pivot
            j -= 1
        Loop
        
        If i >= j Then
            Return j
        End If
        
        Scope
            Dim tmp As LARGE_DOUBLE = pVector[i]
            pVector[i] = pVector[j]
            pVector[j] = tmp
            
            i += 1
            j -= 1
        End Scope
    Loop
    
End Function
 
Function QuickSort( _
        ByVal pVector As LARGE_DOUBLE Ptr, _
        ByVal LeftBound As UInteger, _
        ByVal RightBound As UInteger _
    )As UInteger
    
    If LeftBound < RightBound Then
        Dim PartitionIndex As UInteger = Partition(pVector, LeftBound, RightBound)
        
        Dim PartitionsCount As UInteger = 1
        PartitionsCount += QuickSort(pVector, LeftBound, PartitionIndex)
        PartitionsCount += QuickSort(pVector, PartitionIndex + 1, RightBound)
        
        Return PartitionsCount
    End If
    
    Return 0
    
End Function

@locm · 21.05.2021, 12:25

Сообщение от Quiet Snow

Короче ясно, ARM они захотели

ARM это не только яблоко (тем более что PB для MacOS X существует давно), но и много чего другого, например, планшеты с виндой, устройства на андроиде, малина, микроконтроллеры и т. д.

Сообщение от Quiet Snow

Короче держите резы. Ryzen 3900X

Без сравнения с другими версиями программ этот результат мало что значит.

@Замабувараев · 21.05.2021, 12:30 **[ТС]**

Сообщение от Pro_grammer

FreeBasic_Build_1.05 х86

Сообщение от Quiet Snow

(FreeBASIC Compiler - Version 1.07.2 (2020-12-25)

1. У вас устаревшие версии компилятора, обновите до 1.07.3
2. Возьмите также версию с задником GCC 8.1.0, она быстрее.
3. Добавляйте опцию компиляции -gen gcc.

@Pro_grammer · 21.05.2021, 13:37

Сообщение от Замабувараев

У вас устаревшие версии компилятора

Это как то изменит ситуацию, и оптимизированный вариант станет работать медленнее, чем не оптимизированный?

@Замабувараев · 21.05.2021, 14:49 **[ТС]**

Сообщение от Pro_grammer

Это как то изменит ситуацию, и оптимизированный вариант станет работать медленнее, чем не оптимизированный?

А как вы получите оптимизированную версию без оптимизирующих утилит?

@Quiet Snow · 21.05.2021, 15:32

Сообщение от Pro_grammer

Ну не скажи, уважаемый Quiet Snow! Оптимизация сильная штука.
Вот у тебя один только процессор в общем дороже всего моего компа, и в частности моего процессора примерно в 7 раз
Не оптимизированная версия программы у тебя отработала в среднем за 14.6 сек.
Оптимизированная версия на моём компе отработала за 8.9 сек., на ~ 35% быстрее.
Вот и думай, почему для современных программ людям навязывают такие компы как у тебя, хотя если бы всё оптимизировать и вылизать до байта, как ты любишь, то хватило бы такого компа, как у меня, и ещё бы на 30 % быстрее работало!
PS. И заметь, что скорость разработки тут не страдает, код один и тот же. Мы получаем реальный прирост только лишь сменив один компилятор на другой.

Мы пока ничего не получаем. Реальный прирост делает не компилятор, а твой мозг и твои архитектурные решения.
И скорость разработки страдает, разные задачи часто приходится компилировать сотни раз, проверяя те
или иные вещи, возросшее время компиляции в три раза - это такое себе.
Оптимизировать нужно нормальную задачу, а не какую-то пустотелую сортировку.
Плюс эти промежуточные тесты на утках мало чего дают. В приложении с миксом задач разной структуры
и сложности таких приростов не будет. Эффект вау на лёгких прогонных задачах меня мало интересует.
Касаемо компа, его взял чтобы решить проблему с секвенсором, в итоге нифига не решил.
Работает в RT это чудо как говно и это видно даже по этим результатам, никто и не сомневался
что ядра интел местами по однопотоку вкуснее, но есть нюансы, эти ЦП заточены под тяжёлые, хорошо
кешируемые, сильно распараллеливаемые задачи и в них они действительно неплохи.
А так у меня есть ноут, 3-й пень, целерон 1200 с 98-й виндой и мне его хватает, причём и
второго бы хватало чисто для кодинга, но нужен интернет и максимально быстрая работа с браузером,
для этого кстати мне хватает и X5470, поставлю туда XPx64 и будет отпад. Рязань эту долбаную ещё даже
не настроил толком, времени и хардов свободных нет.

Просто этой всей возьнёй должны не программисты заниматься, а разработчики средств разработки.
И по итогу конечно хочется иметь один файл вида FBC.EXE, как бы не буду заглядывать внутрь, мне это не нужно
доверяю разработчикам. Но если это монстр на 500 мегабайт как у QB64 и ожиданием начала компиляции в
4 секунды - то они уйдут лесом.
Мне нужно что-то не толстое, минимальное, компилирующее в клик, чтобы не ждал пока запустится
один транслятор, второй, третий, пока оно выкакает мне экзешник.
В этом плане старенький QuickBasic вне конкуренции.

Сообщение от Замабувараев

1. У вас устаревшие версии компилятора, обновите до 1.07.3

Наоборот хочу откатиться к версиям в районе 0.22. Мне оно не надо, чё они там пилят.

Добавлено через 32 секунды

Сообщение от Замабувараев

А как вы получите оптимизированную версию без оптимизирующих утилит?

Руками. Автоматическая оптимизация не в приоритете.

@locm · 21.05.2021, 16:20

Сообщение от Quiet Snow

Реальный прирост делает не компилятор, а твой мозг и твои архитектурные решения.

Несогласен. Код пишется на ЯВУ, в нашем случае бейсике, а потом транслируется в машинный код. Как происходит трансляция имеет большое значение. Я выкладывал код Тест быстроты сгенерированного кода
С оптимизацией компилятором код работает в два раза быстрее.

Сообщение от Quiet Snow

Руками. Автоматическая оптимизация не в приоритете.

Это если писать на асме, но если на ЯВУ, руками не получится.

@Pro_grammer · 21.05.2021, 17:39

Сообщение от Quiet Snow

И скорость разработки страдает, разные задачи часто приходится компилировать сотни раз, проверяя те
или иные вещи, возросшее время компиляции в три раза - это такое себе.

Тут видишь какая приятная штука образовалась, компилировать ты можешь хоть тысячи раз, но делай это в процессе разработки как мы любим, хоть с отладчиком, под ФАСМ и самым быстрым образом. А вот на чистовую 1 раз, с хорошей оптимизацией, пусть даже и 20 минут, но если результат того стоит, 1 раз можно и подождать.

Сообщение от Quiet Snow

Реальный прирост делает не компилятор, а твой мозг и твои архитектурные решения.

Нужно уметь это сочетать, тогда и будет реальный результат.

@Quiet Snow · 21.05.2021, 22:44

Сообщение от locm

Это если писать на асме, но если на ЯВУ, руками не получится.

Трансляция одного ВУ в другое ВУ в поисках лучшего конкретного оптимизационного решения -
это лютая, абсолютно бесполезная херня. Спроси любого демщика из нормальной демогруппы
выступавшей годах в 95-х. Они об оптимизации знают всё. И нет каких-то других приёмов оптимизации,
чем общеизвестные. В нормальных, нашпигованных логикой задачах автоматический оптимизатор
может обосраться так, что мама не горюй. Измерение же скоростей на 20 строках кода "этопять".
И да, нормальные люди никогда рекурсию не оставят у себя в серьёзном проекте.
Повторюсь, мы тут ничего сейчас не измеряем, задача не позволяет.

По поводу ассемблера - те кто под x86-64 винду\линукс пишут - применяют и не парятся.
Как бы от него не хотели избавиться "ценители современных тенденций" - это ключевое звено в оптимизации.
И то, что Фред там что-то считает - это его личное мнение, у меня своё есть, пусть дальше "прогибается
под изменчивый мир" и жопу лижет, с ним всё ясно, захотел лёгких денег, потом начнутся проблемы.
Лучшие годы как PB так и FB - далеко позади. С таким подходом оно всё будет загибаться дальше.
Перерождения не случится, это вопрос чисто идеологический.
Фортран тому прекрасный пример, умерло поколение программистов - умер язык.

Сообщение от Pro_grammer

Нужно уметь это сочетать, тогда и будет реальный результат.

Всё равно будешь вынужден тестировать, в слепую, на поверку, компилировать не будешь.
Качество компилятора важно, когда ты чётко понимаешь, что он делает на НУ, когда ты это не пасёшь,
то - один фиг, это как подбросить монетку: соптимизирует или сделает хуже. В нормальной задаче конечно.
Поэтому архитектура в сто крат важнее, т.к. её ты знаешь и тут даже лучше, чтобы компилятор не делал
лишних телодвижений, а какую-то минимальную базу, которая в него заложена. Это даст в разы большую
стабильность, чем слепо полагаться на автоматический "супер умный" оптимизатор.

По поводу чистового варианта - если будут билды от разработчиков - можно потестить свои проекты,
почему нет, разумеется если оно будет компилироваться, а не начнёт мозги компостировать варнингами.
А самому чё-то там крутить одно к другому припаивать - нафиг надо, жизнь коротка чтобы тратить
её на этот бред.

@Замабувараев · 22.05.2021, 07:21 **[ТС]**

Сообщение от Quiet Snow

Руками. Автоматическая оптимизация не в приоритете.

Покажите оптимизированную версию вашими руками.

@locm · 22.05.2021, 11:45

Сообщение от Quiet Snow

Спроси любого демщика из нормальной демогруппы выступавшей годах в 95-х.

Они на асме писали. Мы же говорим об ЯВУ, а именно об бейсике. Или вы имеете в виду что демщики писали на бейсике?

Сообщение от Quiet Snow

В нормальных, нашпигованных логикой задачах автоматический оптимизатор
может обосраться так, что мама не горюй.

Предлагаете потратить 10 лет на разработку на асме идеально оптимизированной программы которую можно написать за несколько месяцев на ЯВУ и получить почти такой же результат с применением оптимизирующего компилятора?

Сообщение от Quiet Snow

По поводу ассемблера - те кто под x86-64 винду\линукс пишут - применяют и не парятся.

Сейчас много устройств с ARM процессорами. Напишите прогу полностью для x86 на асме потратив на разработку и оптимизацию много времени и понадобится перенести на ARM, например на малину? Что будете делать?

Сообщение от Quiet Snow

И то, что Фред там что-то считает - это его личное мнение

Его основная цель не увеличение производительности программ, а поддержка большего числа процессоров. Я выше об этом писал. Трансляция в асм не самое лучшее решение, требующее много времени на доработку транслятора для добавления асма нового процессора. Трансляция в Си позволит намного упростить добавление новых платформ.

Сообщение от Quiet Snow

с ним всё ясно, захотел лёгких денег, потом начнутся проблемы.

О каких легких деньгах идет речь?

Он выполняет большую работу по разработке и отладке PB, а стоимость лицензии почти нулевая. Он не требует денег за новые версии. Лицензия покупается один раз и распространяется на все версии в том числе выпущенные после ее покупки. Действительно думаете что так можно много заработать?

Сообщение от Quiet Snow

соптимизирует или сделает хуже.

Современные версии GCC нормально оптимизируют. Есть опыт его использования. Не припомню случая чтобы оптимизация делала хуже если код написан правильно.

@Quiet Snow · 22.05.2021, 15:22

Сообщение от Замабувараев

Покажите оптимизированную версию вашими руками.

В закреплёнке QB можешь посмотреть машинку. Напишешь руками, без книг и интернета такую же,
тогда будешь просить. Иш молодёжь пошла охамевшая. Всё им покажи да докажи.

Новые блоги и статьи Все статьи Все блоги /
сукцессия 29. Переход от одних деревьев на другие делать более или менее вероятностным? anaschu 12.07.2026 Насколько смена типов микоризы — исключительное событие в двухвековой сукцессии? Оценка вероятности в пространстве параметров В текущей версии модели успешно реализован ключевой механизм. . .	сукцессия 27. Думаю, как переделывать уже написанную статью с планами на сукцессию. anaschu 12.07.2026 Анализ соответствия модели требованиям Реализованные компоненты: Механизм закисления почвы через протонную помпу Конкуренция между типами микориз pH как триггер сукцессии C/ P соотношение. . .	Сукцессия 26. Мат модель создана. anaschu 12.07.2026 Модель смены растительных сукцессий посредством управления грибами работает внутри небольшой ячейки почвы, восстанавливающейся после пожара, где ненадолго бывшее царство хвойных снова захватили. . .	Решил проблему с ошибкой пагинации сообщений с сервера на алгоритме обхода дерева "Эстафета хвоста". Hrethgir 12.07.2026 Проблема была в том, что удалялась именно новая кнопка, а не старая. Ни один ИИ не обнаружил это, а сам я смог только когда с работой стало попроще и когда заставил работать будущее автономное. . .
сукцессия 25. Хронология ошибок anaschu 12.07.2026 # От 50-тонного гриба до устойчивого леса: хроника ошибок при построении модели вековой сукцессии микоризы ## О чём эта статья В процессе построения ОДУ-модели (система дифференциальных. . .	сукцессия 24. Промежуточное общее описание модели anaschu 12.07.2026 Хендофф: модель АМ→ЭКМ сукцессии микоризы (ризосфера, 50 лет) Содержание проекта Симуляция вековой (50 лет) экологической сукцессии в почве леса Основные участники: АМ-гриб, ЭКМ-гриб,. . .	сукцессия 23. Более физиологичная физиология, более экологичная экология, более диффурные диффуры. anaschu 12.07.2026 Что реально нашли и починили за эти 5 часов Правило Линдемана (КПД конверсии сахара в тело, kEff) — раньше 100% полученного углерода шло прямо в биомассу гриба; теперь только kEff=0. 5 (после. . .	сукцессия 22. От артефактов к физиологии: калибровка агентной модели грибной сукцессии для воспроизведения сезонной динамики и pH-плато anaschu 11.07.2026 Аннотация В данной работе представлена калибровка агентной модели динамики грибных сообществ (fungal-succession), направленная на устранение нефизичных артефактов (коллапс биомассы, мгновенное. . .

@locm 7140 / 3320 / 341 Регистрация: 28.10.2011 Сообщений: 13,053 Записей в блоге: 7
	20.05.2021, 14:11
	Я думаю что речь идет о изменении существующего транслятора. Вероятно было проще переписать транслятор из асм в Си чем в LLVM. 0

@Quiet Snow Кормпилятор 5044 / 1718 / 409 Регистрация: 25.04.2010 Сообщений: 4,827 Записей в блоге: 2
	20.05.2021, 23:20
	Боже как мне не нравится вот эта вся херня, разбивать диалект по кускам и таскать ещё тысячи говнофайлов. Всё и на PB и на FB было прекрасно и тут начинается это, там быстрее тут быстрее. Да насрать просто. Лишняя возня и гемор. 0

@Quiet Snow Кормпилятор 5044 / 1718 / 409 Регистрация: 25.04.2010 Сообщений: 4,827 Записей в блоге: 2
	21.05.2021, 01:23
	Короче держите резы. Ryzen 3900X Просто откомпилировал версией (FreeBASIC Compiler - Version 1.07.2 (2020-12-25), built for win32 (32bit)) В кастомный кусорт вникать не буду, нафиг надо. 0