LINUX.ORG.RU
ФорумTalks

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


1

4

Я новичок, и мне показалось, что есть такой стереотип в программировании, что системные программисты - «трушные», самые правильные, «настоящие», могут разобраться во всех областях программирования. Откуда взялся этот стереотип?

Перемещено post-factum из development

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

vvviperrr ★★★★★
()

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

Deleted
()
Ответ на: комментарий от slovazap

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

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

HerrWeigel ★★★★
()

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

gh0stwizard ★★★★★
()
Ответ на: комментарий от beastie

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

XoFfiCEr ★★☆☆
()

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

tailgunner ★★★★★
()
Ответ на: комментарий от J

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

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

Redrum
()
Ответ на: комментарий от J

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

makeB
()

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

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

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

hobbit ★★★★★
()
Последнее исправление: hobbit (всего исправлений: 1)
Ответ на: комментарий от hobbit

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

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

J ★★★★
()
Ответ на: комментарий от makeB

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

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

erfea ★★★★★
()
Ответ на: комментарий от J

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

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

hobbit ★★★★★
()

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

vertexua ★★★★★
()
Ответ на: комментарий от soomrack

Системные программисты знают разницу между ++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];
}}}

soomrack ★★★★
()
Ответ на: комментарий от soomrack

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

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

tailgunner ★★★★★
()
Ответ на: комментарий от soomrack

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

imtw
()
Ответ на: комментарий от imtw

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

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

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

soomrack ★★★★
()
Ответ на: комментарий от tailgunner

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

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

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

soomrack ★★★★
()
Ответ на: комментарий от soomrack

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

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

tailgunner ★★★★★
()

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

urxvt ★★★★★
()

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

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

yu-boot ★★★★
()
Ответ на: комментарий от soomrack

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

imtw
()
Ответ на: комментарий от soomrack

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] ?

madcore ★★★★★
()
Ответ на: комментарий от imtw

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

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

soomrack ★★★★
()
Ответ на: комментарий от madcore

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

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

imtw
()

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

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

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

x4DA ★★★★★
()
Ответ на: комментарий от imtw

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

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

x4DA ★★★★★
()
Ответ на: комментарий от soomrack

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

imtw
()
Ответ на: комментарий от x4DA

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

imtw
()
Ответ на: комментарий от hobbit

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

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

r ★★★★★
()
Ответ на: комментарий от x4DA

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

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

Sphinx ★★☆☆
()
Ответ на: комментарий от r

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

imtw
()
Ответ на: комментарий от imtw

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

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

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

soomrack ★★★★
()
Ответ на: комментарий от madcore

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

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

fang
()
Ответ на: комментарий от soomrack

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

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

imtw
()
Ответ на: комментарий от imtw

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

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

soomrack ★★★★
()
Ответ на: комментарий от Zhbert

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

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

quiet_readonly ★★★★
()
Ответ на: комментарий от imtw

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

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

fang
()
Ответ на: комментарий от Sphinx

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

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

x4DA ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.