Как выучить язык С?

[Viete]

Как изучили язык программирования С Вы?
Как посоветуете изучать С?
Это мой второй язык программирования, первым был Python, программировал на нём плотно около полугода, хотел бы изучить С так как на нём написано ядро GNU/Linux.
Заранее спасибо

[Pphantom]

А в чем, собственно, проблема? Брать и учить, C не относится к числу языков с какой-то особо сложной идеологией и т.п. Так что лучше задавайте конкретные вопросы.

Viete в сообщении #1507059 писал(а):

Это мой второй язык программирования, первым был Python, программировал на нём плотно около полугода, хотел бы изучить С так как на нём написано ядро GNU/Linux.

Но вот мотивировку стоило бы дополнительно обдумать. Если у вас нет конкретной задачи, ради которой надо потрошить ядро Linux, то она достаточно сомнительна.

[realeugene]

С - самый низкоуровневый из широко используемых ныне языков высокго уровня. Его используют сейчас только если нужно программировать железо или что-то около него. Ядро операционки, например, драйвера. Для остальных задач он слишком примитивен. В этих околожелезячных областях также нечего делать без понимания, как работает процессор на нижнем уровне: что такое адресное пространство, что такое регистры, какие у процессора существуют команды? Вот с этого и начните, иначе, вам понять идеологию С после питона будет сложно.

[Viete]

Pphantom в сообщении #1507079 писал(а):

А в чем, собственно, проблема? Брать и учить, C не относится к числу языков с какой-то особо сложной идеологией и т.п. Так что лучше задавайте конкретные вопросы.

Viete в сообщении #1507059 писал(а):

Это мой второй язык программирования, первым был Python, программировал на нём плотно около полугода, хотел бы изучить С так как на нём написано ядро GNU/Linux.

Но вот мотивировку стоило бы дополнительно обдумать. Если у вас нет конкретной задачи, ради которой надо потрошить ядро Linux, то она достаточно сомнительна.

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

-- 01.03.2021, 15:17 --

realeugene в сообщении #1507137 писал(а):

С - самый низкоуровневый из широко используемых ныне языков высокго уровня. Его используют сейчас только если нужно программировать железо или что-то около него. Ядро операционки, например, драйвера. Для остальных задач он слишком примитивен. В этих околожелезячных областях также нечего делать без понимания, как работает процессор на нижнем уровне: что такое адресное пространство, что такое регистры, какие у процессора существуют команды? Вот с этого и начните, иначе, вам понять идеологию С после питона будет сложно.

Есть какие-то книги про темы которые вы упомянули, в каких есть информация о работе компьютера и т.п?

[realeugene]

Viete в сообщении #1507147 писал(а):

Да, я как-раз хочу посмотреть и отредактировать систему под свои нужды

Это не для начинающих.

Viete в сообщении #1507147 писал(а):

Есть какие-то книги про темы которые вы упомянули, в каких есть информация о работе компьютера и т.п?

Море. Весь интернет перед вами.

[Pphantom]

realeugene в сообщении #1507137 писал(а):

Его используют сейчас только если нужно программировать железо или что-то около него. Ядро операционки, например, драйвера. Для остальных задач он слишком примитивен.

Пожалуй, все-таки есть еще одна ниша - вычислительное программирование, в нем C довольно активно используется.

Viete в сообщении #1507147 писал(а):

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

Кхм... боюсь, вы несколько переоцениваете собственные потребности (да и возможности).

realeugene в сообщении #1507149 писал(а):

Это не для начинающих.

Да и не для 99% продолжающих. Даже не потому что слишком сложно, а просто совершенно незачем.

[realeugene]

Pphantom в сообщении #1507151 писал(а):

Пожалуй, все-таки есть еще одна ниша - вычислительное программирование, в нем C довольно активно используется.

От безысходности, видимо. Сишная арифметика указателей сильно мешает оптимизации. С другой стороны, машинное обучение сейчас почти всё на питоне в качестве скриптового языка верхнего уровня с сишными низкоуровневыми библиотеками. Которые развивают отдельные люди. А Comsol написан на джаве, вызывающей матричные алгоритмы для собственно перемалывания цифр.

[Pphantom]

realeugene в сообщении #1507156 писал(а):

От безысходности, видимо. Сишная арифметика указателей сильно мешает оптимизации.

Отчасти да (если очень хочется не пользоваться Фортраном ), но действительно хорошие оптимизирующие компиляторы, пожалуй, делаются только для троицы Fortran/C/C++, а по сравнению с последним C в этом качестве все-таки заметно лучше, и языковые средства для решения проблем с побочными эффектами из-за указателей (вроде restrict) в нем теперь есть.

realeugene в сообщении #1507156 писал(а):

С другой стороны, машинное обучение сейчас почти всё на питоне в качестве скриптового языка верхнего уровня с сишными низкоуровневыми библиотеками. Которые развивают отдельные люди. А Comsol написан на джаве, вызывающей матричные алгоритмы для собственно перемалывания цифр.

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

[realeugene]

Pphantom в сообщении #1507161 писал(а):

а по сравнению с последним C в этом качестве все-таки заметно лучше

Ну да, в плюсах рестрикт существует только как нестандартное расширение. Тем не менее, оптимизатор скорее всего у них один с сями.

Pphantom в сообщении #1507161 писал(а):

А сами полуфабрикаты делают почти исключительно на Фортране или Си (да и их последующее использование с другими языками скорее обусловлено незнанием этих, чем необходимостью в использовании других).

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

[Pphantom]

realeugene в сообщении #1507163 писал(а):

Нет конечно же. Не полуфабрикаты, а законченные и высоко оптимизироавнные библиотеки примитивов нижнего уровня.

Ну какая разница? Их же все равно кто-то должен писать.

[realeugene]

Pphantom в сообщении #1507165 писал(а):

Ну какая разница? Их же все равно кто-то должен писать.

Кто-то пишет MKL, кто-то пишет на HDL синтезируемые блоки процессоров, а кто-то вообще разрабатывает техпроцессы производства микросхем. У каждого свой профессиональный инструментарий.

[mustitz]

realeugene в сообщении #1507156 писал(а):

От безысходности, видимо. Сишная арифметика указателей сильно мешает оптимизации.

Оптимизация такая вещь, что ей всегла что-нибудь да мешает. Поэтому находить альтернативу достаточно проблематично, арифметика указателей не самая большая проблема. Куда больше влияет cache friendly и т. п.

realeugene в сообщении #1507163 писал(а):

Ну да, в плюсах рестрикт существует только как нестандартное расширение. Тем не менее, оптимизатор скорее всего у них один с сями.

Ну... по стандарту, в C++ запись по указателю одного типа не инвалидирует указатели другого типа. А это уже частичный restrict, посему есть веротяность, что он реализован.

Ну и проверка

Используется синтаксис C

void f(int *a, int *b, int *x) {
  *a += *x;
  *b += *x;
}
void fr(int *restrict a, int *restrict b, int *restrict x) {
  *a += *x;
  *b += *x;
}
 

Далее

Используется синтаксис Bash

gcc -g -std=c99 -O3 -c main.c
objdump -S main.o
 

Получаем

Используется синтаксис Text

void f(int *a, int *b, int *x) {
    *a += *x;
   0:   8b 02                   mov    (%rdx),%eax
   2:   01 07                   add    %eax,(%rdi)
    *b += *x;
   4:   8b 02                   mov    (%rdx),%eax
   6:   01 06                   add    %eax,(%rsi)  

void fr(int *restrict a, int *restrict b, int *restrict x) {
    *a += *x;
  10:   8b 02                   mov    (%rdx),%eax
  12:   01 07                   add    %eax,(%rdi)
    *b += *x;
  14:   01 06                   add    %eax,(%rsi) 

инструкцию наварили.

[realeugene]

mustitz в сообщении #1507175 писал(а):

Оптимизация такая вещь, что ей всегла что-нибудь да мешает.

Не "всегда". В данном случае, арифметика указателей убивает анализ потоков данных.

mustitz в сообщении #1507175 писал(а):

Ну... по стандарту, в C++ запись по указателю одного типа не инвалидирует указатели другого типа.

А вычислительный алгоритм работает с матрицами интов или даблов. То есть идёт активные чтение и запись одинаковых типов. Рестрикт в сях позволяет подсказать компилятору, что алиасинга не будет. Но вычислить по коду это сам компилятор не может, если ему недоступен код всей программы сразу. И скорее всего далеко не всегда может при глобальной оптимизации кода на уровне всей программы. Отсутствие алиасинга аргументов - это часть внешней семантики функции.

-- 01.03.2021, 18:35 --

mustitz в сообщении #1507175 писал(а):

инструкцию наварили.

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

[mustitz]

realeugene в сообщении #1507178 писал(а):

То есть идёт активные чтение и запись одинаковых типов. Рестрикт в сях позволяет подсказать компилятору, что алиасинга не будет.

Запись обычно идёт по одному указателю, а чтение часто идёт из const указателей. Даже если и будет, несколько избыточных операций чтения из кэша на фоне кэш промахов и TLB промахов вряд ли сильно скажутся на производительности. Если бы это действительно сильно аффектило производительность, то это проблему давно бы активно решали. На сегодня есть restrict, есть аналогичных расширения в С++, но его использование достаточно пассивное, и больше теоретическое.

-- 01.03.2021, 18:39 --

realeugene в сообщении #1507178 писал(а):

Ваши куски ассемблерного кода не соответствуют сишным исходникам. Скорее всего, вы что-то отрезали.

В каком месте?

[realeugene]

mustitz в сообщении #1507201 писал(а):

Запись обычно идёт по одному указателю, а чтение часто идёт из const указателей.

const не влияет на оптимизацию: как раз из-за алиасинга объект по константному указателю может изменяться при записи через неконстантный указатель. Повышение локальности обращений требует игр с представлениями данных в памяти и с указателями не связано никак.

mustitz в сообщении #1507201 писал(а):

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

Я использовал.

mustitz в сообщении #1507201 писал(а):

В каком месте?

По краям, наверное.