А ты им strip делал или всю отладочную информацию туда тоже загнал?

сделал -Wl--strip-all, разница стала X2

Главное — убрать всю лишнюю инфу, которую gcc по умолчанию записывает в бинарник, таблицу символов, например. И тогда они станут примерно одинаковыми.

$ gcc hello.c -o hello.gcc
$ tcc hello.c -o hello.tcc
$ strip hello.gcc 
$ strip hello.tcc 
BFD: hello.tcc: no group info for section .text.__x86.get_pc_thunk.bx
BFD: hello.tcc: no group info for section .text.__x86.get_pc_thunk.bx
strip:hello.tcc: Bad value
$ ls -l hello.tcc 
-rwxr-xr-x 1 sqrt sqrt 2832 Dec 31 13:29 hello.tcc
$ ls -l hello.gcc 
-rwxr-xr-x 1 sqrt sqrt 3168 Dec 31 13:29 hello.gcc

Но вообще +8К размеру бинарника на производительность влияет куда меньше, чем факт того, что это получаются динамически слинкованные бинарники и за собой потянут библиотеки в сотни килобайт размером:

$ ldd hello.tcc 
	linux-gate.so.1 (0xb76fd000)
	libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb7575000)
	/lib/ld-linux.so.2 (0xb7700000)
$ ldd hello.gcc 
	linux-gate.so.1 (0xb77db000)
	libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb7653000)
	/lib/ld-linux.so.2 (0xb77de000)

Почему GCC и CC делают такие жирные бинари?

Если это жирное, то какие же тогда бинарники того же golang'а?

Welcome to XXI век. Здесь в бинарники пихают рантайм и другие вещи. И у Си всякого хлама гораздо меньше чем где-то ещё. Радует только то, что тяжёлые бинарники прибавляют в весе непропорциально «хелловордам» (т.е. гораздо легче чем можно было ожидать). Если нужно пихать бинарники на дискетки, то можно юзать разного рода gzexe.

собери что-нибудь покрупнее. на всякой мелочи на размер могут изрядно повлиять .init и .fini

Нет такого компилятора "CC"

Это алиас или скрипт запуска

vasily@vonbraun:~ % cc --version
FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on LLVM 3.8.0)
Target: x86_64-unknown-freebsd11.0
Thread model: posix
InstalledDir: /usr/bin

Насколько это вообще важно, в плане скорости и тп?

неважно

Почему GCC и CC делают такие жирные бинари?

отладочная информация и тому подобное, удаляй

dron@gnu:~$ gcc webkit.c `pkg-config --cflags --libs  gtk+-2.0 webkit-1.0` 
dron@gnu:~$ du -h a.out 
16K	a.out
dron@gnu:~$ strip -s a.out
dron@gnu:~$ du -h a.out 
12K	a.out
dron@gnu:~$ 

У тебя же наверняка cc и gcc одно и то же. Нужно пробовать собирать с разными ключами -O?, по умолчанию gcc собирает тупой код для простоты отладки.

Если нужно пихать бинарники на дискетки

… то стоит опасаться саблезубых тигров и пещерных медведей. Или тогда ещё не было медведей, а были только динозавры? Не помню, плохо учил древнейшую историю.

древнейшую историю
Военные США используют 8-дюймовые гибкие дискеты
2016

https://geektimes.ru/post/276406/

гдето натыкался на статью, где программа hello world была размером менее 100 байт
но смысл там был именно сделать минимум, удалив все «ненужное», как самоцель
в обычной программе, которая весит мегабайты, такое ненужно

Насколько это вообще важно, в плане скорости и тп?

Размер кода мало связан с его скоростью.

Цикл из 20 инструкций может выполняться быстрее, чем цикл из 10 инструкций. Компилятор вообще иногда nop'ы вставляет, иногда изощрённые, которые несколько байт занимают. От этого код раздувается, но в итоге работает быстрее.

Собери мой тулчейн и ужаснись.

такие жирные бинари? Насколько это вообще важно, в плане скорости и тп?

Сделай бинарю truncate -s0, будет самый быстрый, базарю.

Стандартная бибилотека и рантайм, в них всё дело. Часть их (не знаю какую) компилятор запихивает прямо в исполняемый файл. А TCC как это модно называть «легковесный компилятор», то есть хорошо работающий прототип, могу поспорить что gcc 90-х годов будет выдавать сравнимый объём кода так как с нынешним TCC у них и возможности одинаковые.

P.S. Скомпиль ещё как уже предлагали с musl и clang, интересно как эта «молодёжь» себя по сравнению со «старичком» gcc покажет.

Почему GCC и CC делают такие жирные бинари?

% type cc
cc is /usr/bin/cc
% ls -l /usr/bin/cc
lrwxrwxrwx 1 root root 20 Feb 13  2016 /usr/bin/cc -> /etc/alternatives/cc
% ls -l /etc/alternatives/cc
lrwxrwxrwx 1 root root 12 Feb 13  2016 /etc/alternatives/cc -> /usr/bin/gcc
% 

Если это жирное, то какие же тогда бинарники того же golang'а?

Welcome to XXI век. Здесь в бинарники пихают рантайм и другие вещи.

если бы не линковались статически, то были бы легче. а то для упрощения языка решили от этого отказаться.

Хороший юзер ТС. И темы у него интересные.

Но ведь libc.so.6 практически наверняка есть загруженная в память.

Как это может ускорить? Команды стали выровнены по машинному слову?

Но он же знает, что его запустили как cc. Может по-особенному ведет себя.

Чего ради?
vim же не ведёт себя как vi, если я его так запускаю в дебиане.

Как это может ускорить? Команды стали выровнены по машинному слову?

20 vs. 10. Если 20 команд имеют мало связей между собой, процессор может ставить их на исполнение одновременно. Тогда как 10 сильно связанных по регистрам команд будут ждать одна другую.

Nop'ы. У предсказателей переходов есть некоторые ограничения на количество отслеживаемых команд на каждые 16 или 32 байта. Если переходов слишком много, предсказатель начинает плохо работать. Разбавив плотность хотя бы теми же nop'ами, можно повысить скорость работы. Кажется, об этом даже упоминается в официальных доках по оптимизациям от Intel и AMD. Многобайтные nop'ы используют, чтобы снизить нагрузку на декодер команд. У него тоже есть ограничения на количество разбираемых команд. Один пятибайтный nop оказывается дешевле, чем пять однобайтных.

Сам скомпиль, там нужно-то только скрипт запустить.

не хочу, у меня стоит мобильный процессор от интела, с индексом U. А на нём virtualbox выполняется неспешно очень. Хост-система - Шindoшs. Попробовал в msys2 собрать твой код - не прокатило.

В Win10 есть WSL, в нём собирается. В msys не получится, так как нужен Линукс.