Доработка Burn2Slot

[Sharpnull]

64 занимает место в кэше в два раза больше, чем 32.

И правда, но можно использовать 32-битные числа в x64 приложении и у x64 с регистрами лучше.
Протестировал 4 варианта программы, в которой простое LZSS сжатие: Visual Studio (последняя) - x64 с 64 битными индексами, x64 с 32 битными индексами, x86, MinGW GCC x64 с 64 из MSYS2 (последний). Вышло по времени в секундах выполнения примерно: VS x64+64 и x64+32 - 17.4 с, VS x86 - 17.5 с, GCC x64 - от 15.5 до 17.5. С GCC не понял, сначала было около 15.5, потом то 17, то 16, а от VS стабильно 17.x. Как понимаю, из-за маленького кол-ва переменных, у меня не повлияла замена 64 на 32 бит чисел, а x86 может хуже работать из-за регистров, GCC лучше в среднем.
Дополнительно заменил цикл с do {} while на while () как выше, у GCC x64 осталось также (15-17 с), а вот VS x64+64 - 25.5 с. Разница в 1.46 раз из-за другой записи.
Для VS по умолчанию пустой проект Release. Для GCC такая компиляция:

Код: [Выделить]

gcc -O2 -Wall -Wextra -static -static-libgcc ./main.c ./LZSS.c -o LZSS.exeUPD: В этот раз толку от x86 не было, но тогда был немного другой код, другая версия VS и не проверял на GCC x86, Win7, FX-8300 (или Phenom II X4 945), а сейчас Win10, 5600X.

[Talking_Sword]

О, вижу мои сообщения перенесли в отдельную тему. тем не менее, переименовал тему, так как она больше не о картриджах, а о правке кода Burn2Slot. Надеюсь, модераторы не будут сердиться.

Идентификаторы можно записать в массив и перебирать - медленно, но просто. Вместо кучи switch, можно использовать словари (std::unordered_map) или множества (std::set), которые быстро находят элемент или позволяют проверить наличие элемента. Также есть простой вариант с массивами: например, у нас id от 0 до 255, определяем массив:

Код: [Выделить]

const char* arr[] = {
/* 00 */   "ID00"
/* 01 */ , "ID01"
...
/* FF */ , "IDFF"
};Тогда простая инструкция быстро даёт значение по ключу: str = arr[id]. Это https://en.wikipedia.org/wiki/Lookup_table.

Про массив и сам думал, но мне кажется, это будет неэффективно, придется делать цикл, который проверяет каждый элемент массива, наверно будет долго. Словари или множества - для моего уровня это слишком сложно.

Talking_Sword, я согласен с wolfer, что компиляторы хорошо оптимизируют. Поэтому тебе надо думать над твоей задачей, а не париться над оптимизацией.

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

[Sharpnull]

Про массив и сам думал, но мне кажется, это будет неэффективно, придется делать цикл, который проверяет каждый элемент массива, наверно будет долго.

Нет, не долго. Вы говорите об эффективности, но не знаете как оптимизировать код, тогда никогда ничего не напишите. Нужно соблюдать баланс. Когда пишите для себя на скорую руку, нет смысла тратить время на оптимизацию, а в остальных случаях лучше сразу писать понятный код, используя эффективные методы и алгоритмы насколько возможно, которые не отнимают много времени.
На счёт getManufacturByID() из ID.h, в godbolt.org после оптимизаций (-O2) видны те же проверки каждого ID, единственная оптимизация, это объединение 0x01, 0x04, 0x1C, 0x1F, 0x20 в LUT с "пустыми" промежутками, как я писал про str = arr[id]. Там ещё написан SANYO_ID, но не используется.

[VROdin]

Во-первых, спасибо всем, кто проявил интерес к моей программе, это радует и мотивирует заниматься тем чем я занимаюсь на текущий момент.
Во-вторых, в теме обсуждается компиляторы и их "магические" оптимизации, уверяю что доверять компилятору дело лично каждого, но оптимизировать алгоритмы стоит, так как нет уверенности в том что все компиляторы смогут разрулить говнокод правильно.
Отвечу на вопрос почему это было сделано так, а не как иначе, в контексте штуки написанной на коленке, за пару недель, это устраивало моим подребностям:
1)Добавить максимальную поддержку тех картриджей, информацию о которых я имел на тот момент.
2)Добавить автоматическое определение чипа, я не припомню ни одного приложения, которое делало это до B2S (немного графомании)
На текущий момент я занимаюсь переписыванием ядра приложения и выбрал для этого абсолютно иной подход, надеюсь это приведет к чуть большему числу положительных отзывов  и сдеалет процесс добавление новых картриджей проще

[HayaoYokogawa]

Во-первых, спасибо всем, кто проявил интерес к моей программе, это радует и мотивирует заниматься тем чем я занимаюсь на текущий момент.
Во-вторых, в теме обсуждается компиляторы и их "магические" оптимизации, уверяю что доверять компилятору дело лично каждого, но оптимизировать алгоритмы стоит, так как нет уверенности в том что все компиляторы смогут разрулить говнокод правильно.
Отвечу на вопрос почему это было сделано так, а не как иначе, в контексте штуки написанной на коленке, за пару недель, это устраивало моим подребностям:
1)Добавить максимальную поддержку тех картриджей, информацию о которых я имел на тот момент.
2)Добавить автоматическое определение чипа, я не припомню ни одного приложения, которое делало это до B2S (немного графомании)
На текущий момент я занимаюсь переписыванием ядра приложения и выбрал для этого абсолютно иной подход, надеюсь это приведет к чуть большему числу положительных отзывов  и сдеалет процесс добавление новых картриджей проще

И тебе спасибо за полезный софт