Один из пользователей сервиса Highload.fun Joad Nacer прогнал все задачи через GPT O1 и получил интересный результат:

По 2024 году результат расположился на 20 месте с 3,574 очками, как я понимаю код был на C++. В целом нормально, но я, непрофессиональный кодер на C#, разместился на 23 месте, так что я бы оценил кодерство ИИ на уровне студента 1-го курса непрофильной специальности.

Не являюсь профессиональным программистом на C#, для меня это хобби и много лет меня интересует вопрос, почему косметически минимально изменённая программа на C# может выполняться на десятки процентов или быстрее или медленнее.

Корифеи мне конечно объясняли что мол приложению нужно "прокачаться" перед запуском и даже научили пользоваться бенчмарком для .NET, но забавность еще и в том, что на одной машине бенч может показывать одни результаты, а на другой - другие. И нет, я не про разницу в железе, а о том, что Метод1 на одной машине стабильно быстрее Метода2 на 10%, а на другом ПК - разница просто отсутствует.

Вот и сегодня точно такой же день, я нашёл еще одно условие при котором производительность меняется. Опишу все три что мной уже наёдены:

Первая. Перестановка переменных местами:

int a = 0;
int b = 0;

и следом вариант

int b = 0;
int a = 0;

производительность меняется.

Вторая. Использование for/while:

for(int i = 0; i < 100; i++);
int i = 0; while(i < 100) i++;

еще с 90-х меня учили что в Си-подобных языках конструкции for/while по сути взаимозаменяемы, но в C# почему-то while в некоторых ситуациях оказывается быстрее.

Третья. Обнаружена пару дней назад:

int time = time * 10 + sec - 2;
sec++;

код выше работает медленнее чем

int time = time * 10 + sec++ - 2;

Из множества объяснений самым правдоподобной во всех случаях мне показалась гипотеза о том, в каких случаях какие значения оказываются в регистрах ЦПУ. Возможно это и так, но объяснение объяснением, а вопросы к компилятору всё равно останутся.

В одной из недавних статей узнал про сайт HighLoad.fun, было интересно решить несколько задач и забраться в лидеры. Если кто-то любит highload задачи, то зову принять участие. Общался с автором проекта HL в телеграме - отзывчивый добродушный человек, планируется версия сервера 2.0 с новыми плюшками. Может и выглядит как реклама, но моя заинтересованность чисто спортивная, я решаю такие задачи сколько себя помню, это как кроссворды для меня, а без конкуренции нет желания улучшать результат. В секции C++ конечно соревновательный дух активнее, но я пишу на C# и там результатов не так много.

Тестировал всякое для ATARI XL/XE и написал небольшую демку в 106 Байт.

Чтобы понимать куда именно смотреть - тут экран 48х24, то есть 1152 байта, но в ОЗУ весь экран представлен всего 48 байтами, еще 78 байт (кто захочет посчитать 48+78=126, тут просто кодом реализованы однотипные строки) для программирования видеочипа, которому объяснено, что каждая строка на экране смотрит на одну и ту же часть ОЗУ, так мы заполняем весь экран. Для получения нестандартного узора используется 8 байт и перепрограммирование таблицы символов. Рисунок изначально подбирается так чтобы формировался равномерный узор. Для плавности движения используется VSYNC, анимация реализована битовым сдвигом.

.include "atari.asm"
    *= $3000
	lda #48
?copy
	sta screen-1, y
	dey
	bpl ?copy
;	ldy #$00
	iny
?copydl
	lda #$42
	sta dlist2, y
	iny
	lda #<screen
	sta dlist2, y
	iny
	lda #>screen
	sta dlist2, y
	iny
	cpy #72
	bne ?copydl
	lda #>font_data
	sta CHBAS
	lda #$23
	sta SDMCTL
	lda #<dlist
	sta SDLSTL
	lda #>dlist
	sta SDLSTL+1
?main
	ldx #1
?start
	lda RTCLOK+2
?wait
	cmp RTCLOK+2
	beq ?wait
	dex
	bpl ?start
?ring
    lda font_data, x
	asl
	adc #00
	sta font_data, x
	inx
	cpx #08
	bne ?ring
	beq ?main
dlist
	.byte $70, $70, $70
dlist2
	*= dlist2+72
	.byte $41, <dlist, >dlist
screen
	*= $7400
font_data
	.byte ~11000011
	.byte ~10011001
	.byte ~00100100
	.byte ~01000010
	.byte ~01000010
	.byte ~00100100
	.byte ~10011001
	.byte ~11000011

upd: -1 байт от @vadimr

upd: -1

Интересный механизм генерации экрана для ATARI XL/XE. Из-за особенности работы видеочипа мы можем для каждой строки сканирования указать видеорежим и то, с какого участка памяти брать данные для строки.

На картинке можно увидеть зоны хода луча, когда он выключен, это Horizontal Retrace и Vertical Retrace, соответственно интервал между строками и между следующими кадрами. В эти интервалы можно выполнять код, который будет делать что-то интересное для нас. Тут будем переключать таблицы символов. Зачем это нужно? Есть текстовый режим графики 40х24 с пятью цветами, который можно использовать для игр, но мы сильно ограничены в рисовании контента динамически, так как это по сути спрайты ориентированные по знакоместам. Символы в XL/XE представлены таблицей в 128 штук (1024 байт) и мы можем рисовать изображение внутри кодовой таблицы, а потом выводить символы в виде текста. Кажется, что 128 символов не хватит чтобы заполнить экран в 40х24=960 байт, вот тут мы и получаем профит.

Новый экран будет (условно) выглядеть так:

ABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890!@#$

И так 24 раза. После каждых 8 строк сканирования (1 знакоместо) мы сдвигаем кодовую таблицу на 40*8 байт, где уже готово изображение для второй порции строк и т.д. То есть рисуем в памяти где участок для кодовой таблицы, а видеочип рисует их как символы. Мы получаем динамическую генерацию экрана и 5 цветов.

Когда я такое придумал, то думал, что это изобретение века, но потом нашёл информацию о таком способе: Источник 1, источник 2.