farwayer Сообщения

farwayer	# 8 лет, 7 месяцев назад
Темы: 12 Сообщения: 181 Участник с: 30 апреля 2010	Natrio Или вы настолько верите, что волшебный оптимизирующий компилятор САМ превращает обычный код в векторные инструкции процессора? Вот, кстати, забыл про это написать. Если ты не будешь знать, во что компилятор преобразует твой код, ты в жизнь не напишешь код, который свернется в SIMD. А то, блин, дожили до времени, когда C/C++ программер не знает, что такое стек и почему нужно проверять длину входящих данных. Ассемблер нужно знать, не для того, чтобы на нем писать. Это очень редко бывает необходимо. Знать нужно, чтобы более эффективно и безопасно писать на том же самом C/C++.

# 8 лет, 7 месяцев назад

Сообщения: 181

Участник с: 30 апреля 2010

Natrio
Или вы настолько верите, что волшебный оптимизирующий компилятор САМ превращает обычный код в векторные инструкции процессора?

Вот, кстати, забыл про это написать. Если ты не будешь знать, во что компилятор преобразует твой код, ты в жизнь не напишешь код, который свернется в SIMD. А то, блин, дожили до времени, когда C/C++ программер не знает, что такое стек и почему нужно проверять длину входящих данных.

Ассемблер нужно знать, не для того, чтобы на нем писать. Это очень редко бывает необходимо. Знать нужно, чтобы более эффективно и безопасно писать на том же самом C/C++.

farwayer	# 8 лет, 7 месяцев назад
Темы: 12 Сообщения: 181 Участник с: 30 апреля 2010	akorop А сколько будет стоить падение такой программы? Или задержка внедрения новой фичи? Вот уж где ассемблером и не пахнет, я думаю, так это в подобных областях. Интересно было бы узнать реальное положение, а не имхами мериться. Да, конечно, гугл заниматься такой ерундой, как переписывание своих сервисов на ассемблере, не будет. Слишком мелко и специфично. Ко всему прочему и цена поддержки возрастает. Там поступают по принципу переиспользования технологий. Оптимизацией занимаются совсем другие команды. Взять хотя бы релиз нового языка go от гугл. Т.е. разрабатывается инструмент, где и происходят оптимизации под платформу. А потом этот инструмент используется для разработки более высокоуровневых сервисов. Или фейсбук с его HHVM: PHP -> байт-код с JIT. А что есть есть JIT, как не оптимизация с привязкой к архитектуре? akorop Во-вторых, в серьёзном производстве замена программы подразумевает такую кучу затрат Это каких? Никто не говорит, про полное переписывание на ассемблере. Оптимизируются критические места на месте затыка, прогоняются авто-тесты, чтобы не было косяков. Что-то мне подсказывает, что взять другой контроллер подребует больших затрат. Хороший вариант: берем более быстрый микроконтроллер той-же серии, совместимый по пинам, +1$ предположим. На серии в 10к единиц имеем +10к $. Плохой вариант: другой, не совместимый по пинам и разводке, контроллер -> перепроектирование платы, создание опытного обзазца, тестирование, возможно, переписывание и тестирование прошивки... Конечно, если железо с самого начала было выбрано неудачно - тут уж никакая оптимизация не поможет. akorop Если уж на то пошло, то программа для современного x86 процессора - это фактически байт-код, только интерпретируется он не программно, а аппаратно. Я уже, кажется, раньше писал про микрокод. Как бы он не менялся, но xor rax, rax бедет всегда быстрее mov rax, 0. akorop Единственное осмысленное использование ассемблера - это крохотные вставки в программе на ЯВУ. И цель этих вставок - не повышение вычислительной эффективности самой вставки, а реализация чего-то такого, что в языке выразить нечем. Спорно. Пример с x264 вам уже приводили. А полагаться на оптимизацию компилятора как на серебряную пулю тоже не стоит. Он не идеален, его тоже люди пишут. akorop А что касается спроса, то я погуглил маленько, и первые же ссылки (например, тут и тут) показали, вполне ожидаемо, что спроса на ассемблер-программистов нет вообще. ...это примерно как готовиться в космонавты. А кто про спрос говорил? Тут к гадалке не ходи, востребованость таких спецов минимальна. Но потому они и ценятся. Ведь кто-то должен быть космонавтом, правда? Не всем же по земле ползать :) naszar Ну вот, опять к желтой прессе отсылают.. Зачем про мыша плохо говоришь?

farwayer

# 8 лет, 7 месяцев назад

Темы: 12

Сообщения: 181

Участник с: 30 апреля 2010

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

Да, конечно, гугл заниматься такой ерундой, как переписывание своих сервисов на ассемблере, не будет. Слишком мелко и специфично. Ко всему прочему и цена поддержки возрастает. Там поступают по принципу переиспользования технологий. Оптимизацией занимаются совсем другие команды. Взять хотя бы релиз нового языка go от гугл. Т.е. разрабатывается инструмент, где и происходят оптимизации под платформу. А потом этот инструмент используется для разработки более высокоуровневых сервисов. Или фейсбук с его HHVM: PHP -> байт-код с JIT. А что есть есть JIT, как не оптимизация с привязкой к архитектуре?

akorop
Во-вторых, в серьёзном производстве замена программы подразумевает такую кучу затрат

Это каких? Никто не говорит, про полное переписывание на ассемблере. Оптимизируются критические места на месте затыка, прогоняются авто-тесты, чтобы не было косяков. Что-то мне подсказывает, что взять другой контроллер подребует больших затрат.
Хороший вариант: берем более быстрый микроконтроллер той-же серии, совместимый по пинам, +1$ предположим. На серии в 10к единиц имеем +10к $.
Плохой вариант: другой, не совместимый по пинам и разводке, контроллер -> перепроектирование платы, создание опытного обзазца, тестирование, возможно, переписывание и тестирование прошивки...
Конечно, если железо с самого начала было выбрано неудачно - тут уж никакая оптимизация не поможет.

akorop
Если уж на то пошло, то программа для современного x86 процессора - это фактически байт-код, только интерпретируется он не программно, а аппаратно.

Я уже, кажется, раньше писал про микрокод. Как бы он не менялся, но xor rax, rax бедет всегда быстрее mov rax, 0.

akorop
Единственное осмысленное использование ассемблера - это крохотные вставки в программе на ЯВУ. И цель этих вставок - не повышение вычислительной эффективности самой вставки, а реализация чего-то такого, что в языке выразить нечем.

Спорно. Пример с x264 вам уже приводили. А полагаться на оптимизацию компилятора как на серебряную пулю тоже не стоит. Он не идеален, его тоже люди пишут.

akorop
А что касается спроса, то я погуглил маленько, и первые же ссылки (например, тут и тут) показали, вполне ожидаемо, что спроса на ассемблер-программистов нет вообще. ...это примерно как готовиться в космонавты.

А кто про спрос говорил? Тут к гадалке не ходи, востребованость таких спецов минимальна. Но потому они и ценятся. Ведь кто-то должен быть космонавтом, правда? Не всем же по земле ползать :)

naszar
Ну вот, опять к желтой прессе отсылают..

Зачем про мыша плохо говоришь?

farwayer	# 8 лет, 7 месяцев назад
Темы: 12 Сообщения: 181 Участник с: 30 апреля 2010	akorop Ну на сколько так можно ускорить вычисления? На 20%? Да гори они огнём. Если это офисная задача - подождут: пользователь, который готов секунду (минуту, час, день) ждать, подождёт и 1.2 секунды (минуты, часа, дня). А если это задача реального времени, надо просто мощнее процессор взять и не закладывать бомбу под будущее сопровождение. Не нужно так категорично. Для какого-нибудь гугла или фейсбука сэкономить хотя бы 5% вычислительных мощностей - уже большая экономия. А для высокочастотных торгов милисекунды вообще стоят миллионы долларов. Или более приближенная ситуация. Для какого-нибудь устройства выбрали микроконтроллер, спроектировали плату и отправили в производство. А потом выяснилось, что в некоторых ситуациях его мощности немного не хватает. И тут возникает вопрос: отправить партию в брак, взять другой микроконтроллер, который, возможно, потребует перепроектировки платы, или попробовать оптимизировать несколько функций на ассемблере? vasek Конечно, прогресс на месте не стоит — появляются другие процессоры, другие более приспособленные языки, но в их основе лежит тот же простой ассемблер Не все так просто. Взять хотя бы интерпретируемые языки. Или языки с трансляцией в байт-код. Да, интерпретаторы или виртуальные машины таких языков работают "нативно". Но вот сами программы связаны с процессорными командами уже косвенно. Появляется дополнительный уровень абстракции.

farwayer

# 8 лет, 7 месяцев назад

Темы: 12

Сообщения: 181

Участник с: 30 апреля 2010

akorop
Ну на сколько так можно ускорить вычисления? На 20%? Да гори они огнём. Если это офисная задача - подождут: пользователь, который готов секунду (минуту, час, день) ждать, подождёт и 1.2 секунды (минуты, часа, дня). А если это задача реального времени, надо просто мощнее процессор взять и не закладывать бомбу под будущее сопровождение.

Не нужно так категорично. Для какого-нибудь гугла или фейсбука сэкономить хотя бы 5% вычислительных мощностей - уже большая экономия. А для высокочастотных торгов милисекунды вообще стоят миллионы долларов.

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

vasek
Конечно, прогресс на месте не стоит — появляются другие процессоры, другие более приспособленные языки, но в их основе лежит тот же простой ассемблер

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

farwayer	# 8 лет, 7 месяцев назад
Темы: 12 Сообщения: 181 Участник с: 30 апреля 2010	arcanis Методом тыка обнаружил, что нажимать нужно на самый край кнопки =) От спасибо тебе, добрый человек! А то я пару раз попробовал и смирился, что не работает. Ни разу в край не попал :)

farwayer	# 8 лет, 7 месяцев назад
Темы: 12 Сообщения: 181 Участник с: 30 апреля 2010	lampslave ТС вообще-то exec mate-session уже добавил. В /etc/skel/.xinitrc еще d-bus сессия стартует. А не со слимом ли это, случайно, проблема? https://wiki.archlinux.org/index.php/Display_Manager#Incompatibility_with_systemd Можно попробовать поставить lightdm, как рекомендуют для mate.

farwayer

# 8 лет, 7 месяцев назад

Темы: 12

Сообщения: 181

Участник с: 30 апреля 2010

lampslave
ТС вообще-то exec mate-session уже добавил.

В /etc/skel/.xinitrc еще d-bus сессия стартует.

А не со слимом ли это, случайно, проблема? https://wiki.archlinux.org/index.php/Display_Manager#Incompatibility_with_systemd
Можно попробовать поставить lightdm, как рекомендуют для mate.

farwayer	# 8 лет, 7 месяцев назад
Темы: 12 Сообщения: 181 Участник с: 30 апреля 2010	RAMZAY Еще возник вопрос:в чём разница между fasm и nasm ? Они ведь оба поддерживают макросы. Да по мелочам различаются. Например, nasm может добавлять отладочную информацию, что иногда бывает полезно. Зато fasm'у не нужен линковщик: он может сам собирать исполняемый elf, когда как после nasm нужно еще прогонять ld или gcc. Макроязык у fasm намного более развит, но проявляться это начинает на более-менее больших проектах (KolibriOS и MenuetOS, как пример - две операционки полностью написанные на ассемблере). Поддержка инструкций у обоих одинаково хороша. fasm мне нравится своей внутренней простотой. Там нет ни одного лишнего символа. Как сказал один товарищ: "Nasm разрабатывают толковые ребята, но fasm написал один гениальный человек" :) Aivar Или компактный машинный код уже не в моде? Так одно другому не мешает. Макросы нужны, чтобы упростить некоторые вещи. Пример. ARM с командами thumb2. Нельзя поместить 32-битное значение сразу в регистр одной инструкцией. Сначала помещается младшее полуслово в младшую часть регистра, потом старшее полуслово в старшую. Пишется макрос macro mov32 reg, val { movw reg, val and 0xffff movt reg, (val shr 16) and 0xffff } и жизнь сразу становится легче :)

farwayer

# 8 лет, 7 месяцев назад

Темы: 12

Сообщения: 181

Участник с: 30 апреля 2010

RAMZAY
Еще возник вопрос:в чём разница между fasm и nasm ? Они ведь оба поддерживают макросы.

Да по мелочам различаются. Например, nasm может добавлять отладочную информацию, что иногда бывает полезно. Зато fasm'у не нужен линковщик: он может сам собирать исполняемый elf, когда как после nasm нужно еще прогонять ld или gcc. Макроязык у fasm намного более развит, но проявляться это начинает на более-менее больших проектах (KolibriOS и MenuetOS, как пример - две операционки полностью написанные на ассемблере).
Поддержка инструкций у обоих одинаково хороша.

fasm мне нравится своей внутренней простотой. Там нет ни одного лишнего символа. Как сказал один товарищ: "Nasm разрабатывают толковые ребята, но fasm написал один гениальный человек" :)

Aivar
Или компактный машинный код уже не в моде?

Так одно другому не мешает. Макросы нужны, чтобы упростить некоторые вещи. Пример. ARM с командами thumb2. Нельзя поместить 32-битное значение сразу в регистр одной инструкцией. Сначала помещается младшее полуслово в младшую часть регистра, потом старшее полуслово в старшую. Пишется макрос

macro mov32 reg, val {
    movw reg, val and 0xffff
    movt reg, (val shr 16) and 0xffff
}

и жизнь сразу становится легче :)

farwayer	# 8 лет, 7 месяцев назад
Темы: 12 Сообщения: 181 Участник с: 30 апреля 2010	Jisatsu lampslave И кстати, про настоящую яву они не правду говорят - у меня заработало на openjdk. Они говорят только то, что на Sun JDK будет работать стабильнее и быстре, не более того. Уже не говорят http://youtrack.jetbrains.com/issue/IDEA-113594#tab=Comments

farwayer

# 8 лет, 7 месяцев назад

Темы: 12

Сообщения: 181

Участник с: 30 апреля 2010

Jisatsu
lampslave
И кстати, про настоящую яву они не правду говорят - у меня заработало на openjdk.
Они говорят только то, что на Sun JDK будет работать стабильнее и быстре, не более того.

Уже не говорят http://youtrack.jetbrains.com/issue/IDEA-113594#tab=Comments

farwayer	# 8 лет, 7 месяцев назад
Темы: 12 Сообщения: 181 Участник с: 30 апреля 2010	RAMZAY Меня этот выбор между gas(ат&т) и nasm(интел) прям разрывает. Просто боюсь выбрать не то,а как известно учить с нуля проще чем переучиваться и ломать мозг. Natrio и maisvendoo правильно говорят: синтаксис - дело десятое. Намного важнее понимать архитектуру процессора: регистры, наборы команд, виды адресаций, таблица прерываний и т.д. Это огромный пласт информации, даже если не касаться предсказаний переходов, устройства кэша, микрокода и еще многих интересных, но сложных вещей. Но, фломастеры-фломастерами, а у меня АТ&Т синтаксис не нравится категорически своей избыточностью: $ перед числами, % перед регистрами, ненужные постфиксы и префиксы к командам. А addl -0x40(%ebx,%ecx,0x4),%eax вместо более человеко-читаемого add eax, [ebx+ecx*4-0x40] вызывает несварение мозга. Из компиляторов мне нравится fasm. Минимализм в действии. А его макросы способны творить чудеса :) Из ресурсов могу посоветовать http://wasm.ru. Правда, он сейчас в ремонте, но форум вполне себе функционирует и есть раздел для новичков и по asm в unix. Немного офтопа: Приехала тут на днях отладочная платка с ARM на борту (STM32). После CISC x86 архитектуры, где скоро будет команда "mkcoffee", RISC заставляет моё сознание забиться в самый темный уголок и плакать. Но, блин, красиво. Особенно условные команды.

farwayer

# 8 лет, 7 месяцев назад

Темы: 12

Сообщения: 181

Участник с: 30 апреля 2010

RAMZAY
Меня этот выбор между gas(ат&т) и nasm(интел) прям разрывает. Просто боюсь выбрать не то,а как известно учить с нуля проще чем переучиваться и ломать мозг.

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

Но, фломастеры-фломастерами, а у меня АТ&Т синтаксис не нравится категорически своей избыточностью: $ перед числами, % перед регистрами, ненужные постфиксы и префиксы к командам. А

addl -0x40(%ebx,%ecx,0x4),%eax

вместо более человеко-читаемого

add eax, [ebx+ecx*4-0x40]

вызывает несварение мозга.

Из компиляторов мне нравится fasm. Минимализм в действии. А его макросы способны творить чудеса :)

Из ресурсов могу посоветовать http://wasm.ru. Правда, он сейчас в ремонте, но форум вполне себе функционирует и есть раздел для новичков и по asm в unix.

Немного офтопа:
Приехала тут на днях отладочная платка с ARM на борту (STM32). После CISC x86 архитектуры, где скоро будет команда "mkcoffee", RISC заставляет моё сознание забиться в самый темный уголок и плакать. Но, блин, красиво. Особенно условные команды.

farwayer	# 8 лет, 9 месяцев назад
Темы: 12 Сообщения: 181 Участник с: 30 апреля 2010	Спасибо за статью и отдельно за lsblk :) Чем-то напоминает mnttools ( https://aur.archlinux.org/packages/mnttools/ ), только добавлены настройки мотирования по типу ФС. А разве без sudo работать не будет, если пользователь состоит в группе storage? Кстати, /media больше нету. Теперь предлагают все монтировать в /mnt.

farwayer

# 8 лет, 9 месяцев назад

Темы: 12

Сообщения: 181

Участник с: 30 апреля 2010

Спасибо за статью и отдельно за lsblk :)
Чем-то напоминает mnttools ( https://aur.archlinux.org/packages/mnttools/ ), только добавлены настройки мотирования по типу ФС.
А разве без sudo работать не будет, если пользователь состоит в группе storage?
Кстати, /media больше нету. Теперь предлагают все монтировать в /mnt.

farwayer	# 8 лет, 9 месяцев назад
Темы: 12 Сообщения: 181 Участник с: 30 апреля 2010	1. Проверить хэш образа 2. Попробовать с другой флешкой 3. Memtest не мешало бы тоже прогнать (есть на образе) PS. Под виндой тоже лучше через dd писать