Есть такая программа - Microsoft Excel. Полезная штука, но её активно применяют не совсем для обработки данных, ей пользуются для визуализации процессов, алгоритмов. Базовых инструментов хватает чтобы делать много интересных вещей, но до сего дня, когда мне нужен был скриншот части таблицы, я просто делал его с помощью Win+Shift+S. Но, зная давно о том что в Whatsapp можно вставлять таблицу в виде картинки, я как-то не подумал что так можно делать быстро и точно скриншоты участков, особенно если хочется сделать потом анимацию GIF.

То есть выделяем участок в Excel, копируем в буфер обмена, переключаемся в десктопную версию Whatsapp и вставляем. Кусок таблицы вставится как PNG картинка, которую прям на том же экране можно скачать в один клик. Но и это еще не всё, я открыл Paint.Net и вставил из буфера кусок таблицы и он вставился как картинка. Чудеса.

Да-да, я знаю, что вы могли о таком знать уже лет 10 XD ну что поделать, может кто-то такой же как я жираф.

Один из пользователей сервиса 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.