Системные программисты

с приходом пхпшников, очевидно

Потому что без системщины нихрена не было бы.

В программировании много всяких стереотипов.

+

чтобы позлить пхпешников очевидно.

И кто такие, по-твоему, «системные программисты»?

И кто такие, по-твоему, «системные программисты»?

Очевидно же, что они системы программируют.

Это отсылка к архитекторам вестимо, не?

The Programmer Hierarchy ☺

Да

Прикольно рубисты выше сиплюсплюсников.

Я когда писал BIOS (прошивка для EEPROM) это системное программирование. Но никаких the programmer hierarchy так что...

Потому что когда-то давно оно так и было.

Прикольно рубисты выше сиплюсплюсников.

Из графа это никак не следует.

На C++ можно писать и не знать вообще ничего о системщине, байтах, битах hex-ах - все зависит от задачи. Таких c++-ников qt-истов очень, и очень много. Словом язык не показатель знаний.

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

Это, разумеется, не отменяет того, что и среди прикладников есть изумительные профессионалы, и среди системных - халтурщики.

tailgunner: не надо на 5.1 отвечать.

системное программирование всё же на самом деле одна из самых сложных вещей

В чем сложность, в синтаксисе?

Таких c++-ников qt-истов очень, и очень много.

фреймворкофобия?

Как раз синтаксис - дело десятое. (Ты про ассемблер, что ли? Так на нём пишется ничтожная часть кода, дело не в нём.)

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

Сложность в том, что разработка мало абстрагирована от «железа», со всеми вытекающими последствиями.

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

Системные программисты знают разницу между ++k и k++.

И на x86 вместо вот такой реализации С=A*B,

for(k=0;k<1000;++k){
    for(n=0;n<1000;++n){
         for(z=0;z<1000;++z)
              c[k][n] = a[k][z]*b[z][n];
}}}

будут использовать такую (ибо быстрее):

for(k=0;k<1000;++k){
    for(n=k+1;n<1000;++n){
         buf[k,n] = b[n,k];
}}

for(k=0;k<1000;++k){
    for(n=0;n<1000;++n){
         for(z=0;z<1000;++z)
              c[k][n] = a[k][z]*buf[n][z];
}}}

Сложность в том, что разработка мало абстрагирована от «железа», со всеми вытекающими последствиями.

Сложность не столько в близости к железу, сколько в отсуствии привычных сервисов ОС (при отладке драйвера даже отладочная печать через жо^Wлог).

buf[k,n] = b[n,k];

WAT

Про разницу скорости прекремента и посткремента знают не только системные программисты, но и такие непрограммисты как я. А вот знают ли ъ-системщики про то, что многомерные массивы такого вида медленны (и почему?), и что предпочтительнее использовать сложную индексацию в духе фортрана?

В данном случае это непрерывные куски памяти size(double)*1000*1000.

Потому я и привел два примера. Первый общеизвестный, но с аппаратной т.з. тоже не все знают что происходит и сколько тактов жрет.

Второй пример посложнее, он опирается на организацию работы с памятью DRAM процессором.

Сложность не столько в близости к железу, сколько в отсуствии привычных сервисов ОС (при отладке драйвера даже отладочная печать через жо^Wлог).

Настоящие программисты никогда не проверяют свои программ, это делают только неуверенные в себе люди. (п.8 из правил настоящего программиста).

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

Потому я и привел два примера. Первый общеизвестный

Общеизвестный в каком смысле? На нем проверяют, знает ли программист о существовании «оператора 'запятая'»?

Потому как это чуть ли не единственное настоящее программирование, в отличии от этого вашего мейнстрима по типу Java enterprise, Django, RoR, PHP, etc. Где ни мозгов (ни тем более знаний) почти не нужно чтобы лепить софт довольно не плохого качества.

Потому что в бСССР до сих пор есть стереотип что компьютерщик (простите, от слова «айтишник» я блюю) это обязательно программист, а системщики пишут в основном на ассемблере который самый «трушный».

Сейчас есть масса других смежных профессий. И говорить что труёвее, а что нет довольно трудно. Знание ассемблера совсем не поможет создать телефонную или IP-сеть, равно как и родить сайт или навороченный программный пакет.

Умножение на транспонированную матрицу с целью уменьшения числа промахов кеша - очень известный трюк. Его знают все прикладники и даже многие непрограммисты, работающие с линейной алгеброй. А вот по поводу записи [j] у меня в знаниях пробел: она похожа на обращение к массиву указателей, что как раз с этой точки зрения плохо. Всегда пишу [i+n*j] для ясности, тем более в куда с тамошним выравниванем по банкам памяти по-другому и не получится.

разметка съела пост:

/s/[j]/[i][j]/

for(z=0;z<1000;++z)
c[k][n] = a[k][z]*b[z][n];

будут использовать такую (ибо быстрее):

А не будет ли еще быстрее, если не делать 1000 итераций, чтобы присвоить c[k][n] = a[k][1000]*b[1000][n] ?

В том то и дело, что для одних это трюк, а для других это очевидное решение.

А вот по поводу записи [j] у меня в знаниях пробел: она похожа на обращение к массиву указателей, что как раз с этой точки зрения плохо. Всегда пишу [i+n*j] для ясности, тем более в куда с тамошним выравниванем по банкам памяти по-другому и не получится.

В данном случае особой разницы не будет. Если в коде нужно интерпретировать матрицу как массив векторов, то удобнее [][], но все от контекста зависит.

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

Кстати о неудобстве отладки: когда CUDA ещё не было, я баловался сеточными методами и всякой там редукцией на пиксельных шейдерах. Результаты, естественно, получались в виде текстурок. Отладка часто заключалась в размышлених вида «ага, тут у нас переход от красного к чёрному, по другой оси - от чёрного к синему, а тут фиолетовенький. Значит поле направлено так-то, прекрасно.»

Потому что системное программирование - разработка 3D-движков и библиотек, компиляторов, рантаймов ЯП, jit, разработка сложных драйверов (видео, ФС, например), аудио-видео кодеков, ядер и других подсистем ОС достаточно сложна.

Часто требуются знания о нижележащей архитектуре.

Однако, не все низкоуровневое программирование (потыкать COM-порт, регистр) является системным и сложным.

Зачем тебе текстуры, когда можно юзать обычные compute шейдеры?

Текстуры нужны только для семплирования/интерполяций изображения.

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

Вычислительные шейдеры появились гораздо позже, в directx11. К тому времени у меня уже была tesla, и я всю эту 3D-графику в гробу видел.

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

Это не вопрос сложности это особый скил присущий усидчивым людям - ковырятся в мелких деталях. При чем от общего скила программиста зависит как он будет решать подобные задачи - один будет допоконвеку ковырятся отлаживая хождение данных по регистрам - другой напишет «jvm» чтобы больше никогда такой херней не страдать.

системное программирование - разработка 3D-движков и библиотек, компиляторов, рантаймов ЯП, jit, разработка сложных драйверов (видео, ФС, например), аудио-видео кодеков,

ну это вообще просто пиздец, блядь.
кто тебе так в мозги насрал?
кони, люди...

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

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

Зайди в любой офис не топовой it-компании и опроси программистов. Уверен, что не наберется и 10% тех, кто об этом слышал.

Самого эффективного алгоритма, наверное, нет. Потому что нужно много чего учитывать, размеры кешей L1, L2, L3, тип данных, размер матрицы,..., потом на все это наложить алгоритм быстрого перемножения матриц (которых, кстати, тоже несколько, и они зависят от размеров и плотности матриц).

А не будет ли еще быстрее, если не делать 1000 итераций, чтобы присвоить c[k][n] = a[k][1000]*b[1000][n] ?

То, что он написал это не перемножение матриц, а вообще незнамо что. Оно становится перемножением при замене «=» на «+=»

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

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

Это решение очевидно для всех, кто знает о существовании кеша

Кстати, а причем тут кеш? Тут основная игра ведется вокруг того, что чтение непрерывного куска памяти из DRAM существенно быстрее чтения выборочных байтов. Кеш, конечно, важен (ибо туда и считывается), но в данном примере это вторично.

Без теории компиляции не было бы современного C. Без компьютерной графики (включая игрушки и GUI) не было бы персоналок для этих самых системщиков. Ну и суперкомпьютеры появились раньше полноценных ОСей, и их персонал вряд ли можно назвать системщиками.

Так что вопрос остаётся открытым.

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

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

Все очень просто. есть программы, с которыми работает пользователь (прикладные), а есть служебные (системные)

Вот и вся разница.