@mkostoevr

...

0

@pepsicoca2

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

1

Байт

Вопрос представляется вполне нелепым. Зависит все от задачи, от требований.

0

@LVV

А на каком автомобиле, mkostoevr, Вы поедете в магазин: на двуместном скоростном авто, или на грузовом автомобиле?

4

@mkostoevr

Байт, задача следующая:

Пишется простой компилятор. Есть две идеи, в каком виде хранить данные (точнее их промежуточное представление для дальнейшего перевода в nasm):

"имя переменной", 0, размер типа переменной, состояние (она инициализирована?), количество байт кодирующих размер значения при инициализации, размер значения при инициализации, значение при инициализации

Размер значения указывается потому, что это может быть массив. При этом максимальное значение байт в [значение при инициализации] ограничивается только максимальным размером типа, помноженном на максимальное количество элементов в массиве (sizeof (UINT64) * max (UINT64) == ДОФИГАЛИАРД).

Но такие большие массивы используются редко, так что, хотелось бы кодировать размер [значение при инициализации] переменной, находящийся в [размер значения при инициализации] наименьшим количеством байт, которое указывается уже в переменной [количество байт кодирующих размер значения при инициализации].

Это будет нехило так экономить память.

Всё бы хорошо, однако, так мне придётся тратить больше времени, чтобы достать это значение размера даты переменной, учитывая размер этого [размера даты].

НО! Я могу всегда кодировать размер даты одним и тем же количеством байт. Это неэффективно расходует память, если размер даты небольшой, а для кодирования его значения я буду использовать 8 байт (использоваться из них будет только один).

Что бы в данной ситуации выбрали бы Вы?

0

Байт

mkostoevr, Как я понял, вопрос стоит так. Есть некоторые числа - размеры. Их диапазон от 1 до 2⁶⁴. Как следует хранить эти числа? Отводить на каждое по 8 байт или упаковывать: 1 байт на размер размера + сам размер? Я правильно понял?
Теперь смотри. Сколько может быть переменных? Наверное, не больше сотни. Если в модуле больше переменных - скорее всего он неумело написан. Значит, наш выигрыш не превосходит 700 байтов. Это та цифра, о которой надо говорить? К тому же более изощренный код твоей программы (с упаковкой и распаковкой) сам будет занимать какое-то количество памяти, что сведет даже этот небольшой выигрыш к нулю. К тому же, не стоит забывать и об увеличивающейся трудоемкости разработки и увеличении количества потенциальных ошибок. Так что, имхо, в твоей ситуации не стоит ловить блох и их подковывать

1

@mkostoevr

Байт, понял, благодарю.

0

Evg

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

0

@mkostoevr

Да, я уже пытался писать его по алгоритму "Make it work -> make it right -> make it fast". Теперь приходится его переписывать из-за бесперспективной архитектуры

0

@Kuzia domovenok

mkostoevr, вы компилятор с интерпретатором часом не путаете?

0

@New man

Если данные помещаются в память — ускоряем за счёт памяти. Когда уже не помещаются, выбора нет.

От задачи зависит, в общем.

Добавлено через 3 минуты
С переменными вообще просто. Для обычных ничего не делаешь, для массивов создаёшь скрытую переменную, где хранишь его размер (то есть, две переменные).

0

Байт

В самом деле, разница не так уж велика. Даже посконный машинный код (именно машинный, а не ассемблерный), уже загруженный и привязанный к адресам, в конце концов интерпретируется процессором. А в рамках поставленных в этой теме вопросов, так и вообще нечего говорить.

0

@Kuzia domovenok

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

Добавлено через 1 минуту
Интерпретаторы каких-нибудь простеньких языков, это, напротив, всегда пожалуйста для новичка!

0

Байт

mkostoevr, Твоя проблема - не время/память. От упаковки выигрыш в памяти = 0.1%. Без упаковки выигрыш во времени = 0.01%. И тут, как ни странно, критерием становится сложность разработки. То есть твое личное время, и твоя личная память.

Добавлено через 6 минут
Для примера приведу кое-что из личного опыта. Вот есть база данных. А в ней тексты. И текст может быть длиной от 3-х байтов (есть такие простые русские слова) до 2000. Ну и что? выделять на простое слово 2000 байтов? А записей в базе 1000000. И тут уже приходится, не жалея своего личного времени, что-то придумывать

1

@pepsicoca2

Обычно такие трансляторы на выходе дают Сишный текст. Который потом можно компилировать Сишным транслятором под любую платформу.

0

Evg

Любительский компилятор написать очень сложно. Пока его напишешь, уже перестанешь быть любителем

А многие реально путают компилятор со всякими нанотехнологиями. Т.е. можно на выходе "компилятора" получать текст на Си (см. пост #15), чтобы скормить его существующему компилятору. Я не знаю, как по научному называется такое, но это не компилятор, в том смысле, который подразумеваешь ты, но не правильно понимают некоторые. Есть ещё другая технология, которая может построить реальный объектный код (или ассемблерный файл), но такой код сплошь состоит из вызова библиотечных функций - это так называемый "шитый код". Такое уже под силу любителю, но по прежнему нельзя назвать словом компилятор

Так что я присоединяюсь к тебе - любителю написать простенький, но настоящий компилятор, будет ОЧЕНЬ проблематично

1

@COKPOWEHEU

Какой-нибудь LLVM не поможет? Вроде как gcc через него работает.

0

Evg

0

@COKPOWEHEU

0

Evg

0