Вы очень решительны, если сходу взяли очень широкий фронт работы по всем направлениям одновременно. Мне кажется на реализацию нужно несколько тысяч человеко-часов (1.5-2 года full time). Посмотрел ваши исходники sicql - почти всё ещё предстоит сделать. Несмотря на то, что в своем проекте Boson (NoSql) уже реализовывал отдельно виртуальную машину и компилятор, и B+ Tree индекс, и Storage, и CachedFileIO (аналог pager), но "подружить" эти наработки в целостный продукт довольно сложно. Хочу пожелать вам, как коллеге, терпения и удачи!
Опытным путем на своем SSD замерял, что лучшая скорость записи/чтения блоками 512Кб, а для HDD постраничный 8К (уже не 4Кб). Хотя все это зависит больше от самого железа.
@tzlom прав, что код всё таки "прибит" к OS. Проблема в том, что std::fseek ограничена 4Gb, а _fseeki64() фича MSVC, fseeko64 - GNU C. Насколько мне известно, без выхода за пределы стандартного C++ 64-битное позиционирование сейчас не получить. Печалька. В будущем под win/linux напишу.
Спасибо огромное за review! Действительно, страницы читались дважды при position кратном PAGE_SIZE и length равна PAGE_SIZE. Поправил. И касательно копирования - запретил. Обработку bad_alloc добавил.
Да, спасибо про лицензию. Да, однозначно mmap и/или флаг O_DIRECT в open могут помочь, но это все же вызовы OS, а не C++. Поэтому на текущем этапе избегал (это часть требований).
Классная статья! Олдскулы свело :`) p.s. Вспомнились прерывания BIOS int 10h, режим экрана 13h (320x200), адрес экранного буфера в сегменте A000:0000... Только ты, железо и больше никого. Разве что иногда MS-DOS API на 21h.
Многие начинают со структуры данных Sparse Voxel Octree (SVO), а потом наворачивают. Дешево и сердито. С одной стороны экономит массу памяти по повторяющимся вокселам, во вторых SVO, как структура данных, очень удобна для рейтресинга при растеризации.
Да, есть такое. Всё-таки это не конечный продукт и пока не обрастёт фичами, ранняя оптимизация мешает наглядности. И если вдруг потребуется использовать в продакшн, обязательно последую вашему совету и оптимизирую VM или буду компилировать в нативный код.
На текущий момент тормоза 1:10 в сравнении C. Что, в принципе, приемлемо для учебного проекта.
Вы правы, делать свою VM - это не практично, о чем говорил в первой части. Причина по которой пишу VM и компилятор - это желание самому детально понять как всё работает с нуля. По той же причине не использую парсеры (типа bison). Хочу во всём разобраться и понять. Дай бог закончу, можно будет заменить VM на нативную компиляцию (x86/64) или в WASM, или Java Bytecode.
Если я правильно понял вопрос, то локальная переменная 'c' в функции SUM создана по адресу [32] командой ICONST 10 (аллокация на стеке места под переменную и её инициализация константой 10), по адресу [39] её значение добавляется на вершину стека командой ILOAD #0 для вычислений, без изменения переменной.
Константа которая была передана как второй аргумент изначально создана по адресу [9].
Аргументы функции идут по адресам FP+0 (A=I), FP+1 (B=10) - доступ к ним по команде ARG #index. Локальные переменные по адресам LP+0 (C=10), доступ к ним iload #index.
Наверное, пора писать парсер для построения полноценного Abstract Syntax Tree и генерацию кода из C подобного языка. Уже хочу закрыть гештальт на тему "могу ли написать полноценную виртуальную машину и компилятор" на C++ )))
Интересно! Не сообразил как это сделать, если я не храню количество аргументов, локальных переменных и программа не имеет доступа к регистрам. Подскажите как? Попробую реализовать.
Вы очень решительны, если сходу взяли очень широкий фронт работы по всем направлениям одновременно. Мне кажется на реализацию нужно несколько тысяч человеко-часов (1.5-2 года full time). Посмотрел ваши исходники sicql - почти всё ещё предстоит сделать. Несмотря на то, что в своем проекте Boson (NoSql) уже реализовывал отдельно виртуальную машину и компилятор, и B+ Tree индекс, и Storage, и CachedFileIO (аналог pager), но "подружить" эти наработки в целостный продукт довольно сложно. Хочу пожелать вам, как коллеге, терпения и удачи!
Олдскулы свело, Clipper ?
Опытным путем на своем SSD замерял, что лучшая скорость записи/чтения блоками 512Кб, а для HDD постраничный 8К (уже не 4Кб). Хотя все это зависит больше от самого железа.
@tzlom прав, что код всё таки "прибит" к OS. Проблема в том, что std::fseek ограничена 4Gb, а _fseeki64() фича MSVC, fseeko64 - GNU C. Насколько мне известно, без выхода за пределы стандартного C++ 64-битное позиционирование сейчас не получить. Печалька. В будущем под win/linux напишу.
Спасибо огромное за review! Действительно, страницы читались дважды при position кратном PAGE_SIZE и length равна PAGE_SIZE. Поправил. И касательно копирования - запретил. Обработку bad_alloc добавил.
Спасибо за советы! Про read страниц проверю, а вот про время duration_cast не знал. По исключениям подумаю как обрабатывать.
Спасибо! ACID - хотелось бы реализовать, но пока не разобрался как это делается в NoSQL.
Согласен. Переучиваюсь на проекте с C и Java, на современный C++. Проскакивает местами
Тут нет гаданий. По исходникам и нашел же, что bounds checking создают overhead. Так как я их проверяю сам, поэтому они мне не нужны.
Да, спасибо про лицензию. Да, однозначно mmap и/или флаг O_DIRECT в open могут помочь, но это все же вызовы OS, а не C++. Поэтому на текущем этапе избегал (это часть требований).
Поэтому "тормозят" в кавычках. Да, отладка итераторов вещь полезная, но в моем проекте ненужная.
Классная статья! Олдскулы свело :`)
p.s. Вспомнились прерывания BIOS int 10h, режим экрана 13h (320x200), адрес экранного буфера в сегменте A000:0000... Только ты, железо и больше никого. Разве что иногда MS-DOS API на 21h.
Многие начинают со структуры данных Sparse Voxel Octree (SVO), а потом наворачивают. Дешево и сердито. С одной стороны экономит массу памяти по повторяющимся вокселам, во вторых SVO, как структура данных, очень удобна для рейтресинга при растеризации.
Да, есть такое. Всё-таки это не конечный продукт и пока не обрастёт фичами, ранняя оптимизация мешает наглядности. И если вдруг потребуется использовать в продакшн, обязательно последую вашему совету и оптимизирую VM или буду компилировать в нативный код.
На текущий момент тормоза 1:10 в сравнении C. Что, в принципе, приемлемо для учебного проекта.
Спасибо! Хорошая мысль.
Прикольно! Не думал о реализации WASM виртуальной машины. В будущем можно попробовать. Спасибо.
Вы правы, делать свою VM - это не практично, о чем говорил в первой части. Причина по которой пишу VM и компилятор - это желание самому детально понять как всё работает с нуля. По той же причине не использую парсеры (типа bison). Хочу во всём разобраться и понять. Дай бог закончу, можно будет заменить VM на нативную компиляцию (x86/64) или в WASM, или Java Bytecode.
Если я правильно понял вопрос, то локальная переменная 'c' в функции SUM создана по адресу [32] командой ICONST 10 (аллокация на стеке места под переменную и её инициализация константой 10), по адресу [39] её значение добавляется на вершину стека командой ILOAD #0 для вычислений, без изменения переменной.
Константа которая была передана как второй аргумент изначально создана по адресу [9].
Аргументы функции идут по адресам FP+0 (A=I), FP+1 (B=10) - доступ к ним по команде ARG #index. Локальные переменные по адресам LP+0 (C=10), доступ к ним iload #index.
Наверное, пора писать парсер для построения полноценного Abstract Syntax Tree и генерацию кода из C подобного языка. Уже хочу закрыть гештальт на тему "могу ли написать полноценную виртуальную машину и компилятор" на C++ )))
Интересно! Не сообразил как это сделать, если я не храню количество аргументов, локальных переменных и программа не имеет доступа к регистрам. Подскажите как? Попробую реализовать.