Клавиатура Apple A1243 — для меня удобнее нет. Не смотря на то, что у меня PC, установил Boot Camp и все мультимедийные клавишы работают — очень удобно.
По тактильным ощущениям — превосходно, но как вы боретесь с отсутствием Ins-а, микроскопическим Enter-ом и тильдой в необычном месте?
Бывший глава THQ отметил, что сотрудники 4A Games были вынуждены смириться не только с ограниченными ресурсами, но и с ужасными условиями работы. «Сотрудники 4A сидели за маленькими столиками на складных стульях практически плечом к плечу. Все это больше напоминало кафе в какой-нибудь школе, а не студию по разработке игр», — заявил Джейсон. Он рассказал, что, помимо тесноты, 4A Games приходилось мириться с постоянными перебоями с электричеством — спасали лишь портативные генераторы, которые сотрудники приносили из дома. Рабин хотел отправить разработчикам нормальные офисные стулья, но сделать это не удалось. Во-первых, они просто не поместились бы в офисе. Во-вторых, их пришлось бы везти контрабандой через Польшу, так как в Киеве такая мебель не продается.
А игра ведь получилась отличная. А если бы у них были другие кресла, был бы такой же результат? :)
Меня в большом кожаном кресле «для руководителя» постоянно тянуло на сон. И вот почитав вышеупомянутую новость, озаботился выбором нового устройства для фиксации программиста в удобной позе. Купил такое
И после недели использования могу сказать, что это то что надо! Самое главное, как в рекламе памперсов, — программист чувствует себя сухо и комфортно! Оно легче, мобильней — удобней подкатываться к соседним столам. Правда выше комментаторы пишут, что сетка растянется, это огорчает, но посмотрим.
BIOS на видеокартах — это обычно Serial EEPROM, который отображается в адресное пространство процессора страницами со специальными атрибутами. Это при условии, что пользователь не установил в своих настройках BIOS-а материнской платы галочку "Video ROM BIOS Shadow", тогда всё шоколадно.
Доступ к EEPROM памяти, находящейся на другой плате, через несколько последовательных шин — довольно небыстрая процедура, ширина — 8 бит (да, да — те самые байты), читать надо подряд, иначе процессор обидится, и придётся чуток подождать.
Таким образом, вы должны гордится автором того кусочка, так как он сделал минимально возможный размер кода, исключив функцию определения типа страницы памяти и не дублируя приведённый кусочек кода (он же там больше) под разные сценарии.
Если всё же нужно прочитать двойное слово и аппаратура умеет это делать, то программная эмуляция действий аппаратуры будет заведомо медленнее самой аппаратуры.
В таком случае не было многотомных Optimization Guide-ов, лекций и семинаров посвящённых данному вопросу, так как следую вашей логике — раз аппаратура умеет сделать что-то одной инструкцией, то нечего пытаться заменить это несколькими?
Кроме того, почитайте обсуждение — все фокусируются на быстродействии, а не на размере. В реальных проектах компиляция идёт не с -Os, а с -O2 — ведь большой размер — это даже престижно.
А у вас размер — это самоцель какая-то? На PC расширить память — не проблема, увеличить производительность — да. Для маленьких/встраиваемых устройств, там где размер имеет значение, компилируется с -Os (например в XCode под iOS Release).
По производительности — скажите, где у вас профайлер показывает затыки, и я попробую пооптимизировать. Но опять таки, под какой процессор, какую память?
Как я писал выше, в асме очень важен контекст. В данном случае у меня есть предположение, что где-то выше, эти данные были записаны как байты, а значит читать их двойным словом будет медленно. Не нравятся кэшам такие «оптимизации».
С компилятором GCC: (Gentoo 4.7.3 p1.0, pie-0.5.5) 4.7.3" код такой же, что и у jcmvbkbc.
И ещё интересная инфа, родной маковский nasm (NASM version 0.98.40 (Apple Computer, Inc. build 11) compiled on Feb 6 2013) кодирует push imm8 (без префикса размера) в 5 байт, также как если указать DWORD, а вот с BYTE — в два байта.
По производительности — второй пример был из планировщика ehci_select_hs_interrupt_list — там же не вызывается сброс контроллера каждый раз?
Трудоёмкость — да, очень хочу убедить, так как шишек много. Опять таки, это был первый попавшийся на глаза пример. Если очень интересно — можно ещё найти места, где используются лишние копирования (потому что человеку не под силу держать в голове текущий контекст программы), где инструкции идут не в самом благоприятном порядке — это всё макросами не исправишь (movi — оперативненько!)
И насчёт «размер результата будет в разы больше» это вы погорячились. Я тоже так думал, ровно до тех пор, пока компилятор не стал генерить сравнимый (а зачастую и более короткий и быстрый код). Учитывая разницу во времени на получение этого результата, я крепко призадумался. Потом переписывал только маленькие критические кусочки, потом интринсики.
Ну сколько вы выиграете на всём ядре, килобайт? может быть два? А производительность приносите в жертву. Этот кусочек не единственный, вот в планировщике, подряд
push 5
pop ecx
push 1
pop ebx
push sizeof.ehci_static_ep
pop edx
а конструкции вида
push imm
pop reg32
call proc
вообще сериализация. Ну и не понятно тогда, почему же, если вы оптимизируете под размер, то всё равно много где используется нормальная загрузка значения, как
mov ecx, 4
Где же однообразие кода и подхода?
Да вы и сами, наверняка, знаете, что не всё с кодом оптимально, но из-за ассемблера, изменения становятся вся более трудоёмкими, поэтому начинает преобладать принцип: «работает? — не лезь!»
А Си-шый код так легко перекомпилировать, и новым компилятором, и под новый процессор…
Сейчас использую ассемблер только для PIC-микроконтроллеров — вот там он востребован, так как счёт действительно идёт на байты.
Вы молодцы, ваш проект — замечательный пример программирования на ассемблере, школьникам и студентам для обучения вообще бомба. Но для реальных задач, ИМХО, Сизифов труд.
Оформление красивое. Для полного счастья было бы неплохо указывать размер непосредственных операндов в инструкциях push imm (например ehci.inc:333) push 32
И ещё интересно зачем (там же) используются inc eax; inc eax; и push 32; pop ecx;?
имхо, на асме иначе не выйдет писать.
если код не «радует глаз» — то глаза от всех этих cli; jmp $ в отместку сбегаются в кучку и желание работать пропадает напрочь.
Асмовский код код, который радует глаз — как правило совсем не оптимальный (с точки зрения производительности) код. Для того, чтобы планировщик процессора чувствовал себя хорошо и чтобы задержки (stalls) были минимальными, зависящие друг от друга инструкции нужно разносить, получается некая гребёнка из перемешанных инструкций, относящихся к разным задачам. Параллелизм на уровне планировщика. Посмотрите на код, который генерят современные оптимизирующие компиляторы — да там же месиво, местами очень трудно понимаемое. Вы скажите «а как же out-of-order execution, register renaming, etc. ?» — да, влияние на очень умные процессоры будет на таким значительным, но есть же ещё и Atom-ы. Написать маленькую функцию на асме, которая бы соперничала по скорости с компилятором можно, а большой проект — ИМХО, никак.
Всё не так просто. Проблема затронута очень серьёзная. Часто приходиться разбираться в коде клиента, оптимизировать базу, запросы, сидеть в gdb и искать, чего же там такое делает код, что PHP корки отбрасывает.
Да и ткнуть носом не прокатит, скорее только испортишь себе карму и потеряешь клиента. Было и такое, что втихаря правился код (очень непробивного бюрократа), и потом рапортовалось ему: «мы там сервер подшаманили, всё летает» — тупо, конечно, но и волки сыты, и овцы целы.
Показал графики и все.
Если бы придумать какой-нибудь универсальный общепризнанный (референсный, что-ли) метод оценки производительности, то можно и графики, и потом уже дополнительно клиента готовить к расходам на оптимизацию кода или более высокому тарифному пакету. А пока чаще бывает, что приходит клиент с говнокодом, автора которого найти не представляется возможным, и крутись как хочешь.
Загрузочный диск/флэшка при удаленных системах неприменимы.
Однажды (когда ещё source control системы были мало распространены, да и вообще очень плохо работали с большими бинами) мне очень пригодилась e2undel — получилось полностью восстановить новый файл, случайно удалённый художником на samba-шаре (бэкапы делаю ночью, он туда ещё не успел).
Как говорится, есть две категории людей — те, кто не делает бэкапы, и те, кто уже делает.
В самое яблочко!
Иногда просто быстрее сделать действие другой командой, чем восстанавливать бэкап, особенно если последний полный был 7-10 инкрементальных назад.
Размер бэкапа самой системы такой маленький (~2GB), а современные носители такие большие, что ИМХО, можно не заморачиваться, и держать рядышком загрузочную копию рабочей системы, а ночью mount-rsync-umount.
Всегда нужно держать под рукой загрузочный диск/флешку (например SystemRescueCd), busybox в нескольких директориях тоже не повредит. А вообще странно выглядит ситуация, случайно удалить ifconfig или passwd, под рутом? Для работы с пользователями всегда можно vi /etc/passwd и потом pwconv. Ну и бэкапы, они рулят!
Так у китайцев есть переходники на все случаи жизни. Стоит $10-12. LPT не проверял, а COM той же фирмы — исправно работает. Вот только по длине не уверен. Т.к. «во времена LPT» сканер не заработал на 10-ти метрах экранированного кабеля.
А, такой да. Есть много вариантов рычажков с брутальными колпачками, или колпачки отдельно.
А ещё можно использовать поворотный, или даже с ключом (как замок зажигания в авто) — но они по-дороже будут.
Скажем, кнопочки тоже легко нажимаются неловким движение руки. А так хотя бы будет защита от одновременного нажатия. А вообще может мы говорим о разных типах, не очень понятно куда на клавише сдвигаться?
ИМХО, использование Arduino только для считывания/передачи состояния кнопок — это немного «из пушки по воробьям». Логичнее бы смотрелась схема с переносом задач просчёта индикации на сам Arduino, либо использование гораздо более простого и дешёвого микроконтроллера для передачи данных о кнопках в ноутбук. Я когда-то давно для подобных целей (состояние дип-переключателей + пресеты) использовал моторолловский микроконтроллер MC68HC908JB8, устройство получилось размером чуть больше USB-флешки.
А игра ведь получилась отличная. А если бы у них были другие кресла, был бы такой же результат? :)
Меня в большом кожаном кресле «для руководителя» постоянно тянуло на сон. И вот почитав вышеупомянутую новость, озаботился выбором нового устройства для фиксации программиста в удобной позе. Купил такое
И после недели использования могу сказать, что это то что надо! Самое главное, как в рекламе памперсов, — программист чувствует себя сухо и комфортно! Оно легче, мобильней — удобней подкатываться к соседним столам. Правда выше комментаторы пишут, что сетка растянется, это огорчает, но посмотрим.
Доступ к EEPROM памяти, находящейся на другой плате, через несколько последовательных шин — довольно небыстрая процедура, ширина — 8 бит (да, да — те самые байты), читать надо подряд, иначе процессор обидится, и придётся чуток подождать.
Таким образом, вы должны гордится автором того кусочка, так как он сделал минимально возможный размер кода, исключив функцию определения типа страницы памяти и не дублируя приведённый кусочек кода (он же там больше) под разные сценарии.
По производительности — скажите, где у вас профайлер показывает затыки, и я попробую пооптимизировать. Но опять таки, под какой процессор, какую память?
С компилятором
GCC: (Gentoo 4.7.3 p1.0, pie-0.5.5) 4.7.3"код такой же, что и у jcmvbkbc.И ещё интересная инфа, родной маковский nasm (NASM version 0.98.40 (Apple Computer, Inc. build 11) compiled on Feb 6 2013) кодирует push imm8 (без префикса размера) в 5 байт, также как если указать DWORD, а вот с BYTE — в два байта.
Трудоёмкость — да, очень хочу убедить, так как шишек много. Опять таки, это был первый попавшийся на глаза пример. Если очень интересно — можно ещё найти места, где используются лишние копирования (потому что человеку не под силу держать в голове текущий контекст программы), где инструкции идут не в самом благоприятном порядке — это всё макросами не исправишь (movi — оперативненько!)
И насчёт «размер результата будет в разы больше» это вы погорячились. Я тоже так думал, ровно до тех пор, пока компилятор не стал генерить сравнимый (а зачастую и более короткий и быстрый код). Учитывая разницу во времени на получение этого результата, я крепко призадумался. Потом переписывал только маленькие критические кусочки, потом интринсики.
а конструкции вида
вообще сериализация. Ну и не понятно тогда, почему же, если вы оптимизируете под размер, то всё равно много где используется нормальная загрузка значения, какГде же однообразие кода и подхода?
Да вы и сами, наверняка, знаете, что не всё с кодом оптимально, но из-за ассемблера, изменения становятся вся более трудоёмкими, поэтому начинает преобладать принцип: «работает? — не лезь!»
А Си-шый код так легко перекомпилировать, и новым компилятором, и под новый процессор…
Сейчас использую ассемблер только для PIC-микроконтроллеров — вот там он востребован, так как счёт действительно идёт на байты.
Вы молодцы, ваш проект — замечательный пример программирования на ассемблере, школьникам и студентам для обучения вообще бомба. Но для реальных задач, ИМХО, Сизифов труд.
push 32И ещё интересно зачем (там же) используются inc eax; inc eax; и push 32; pop ecx;?
Да и ткнуть носом не прокатит, скорее только испортишь себе карму и потеряешь клиента. Было и такое, что втихаря правился код (очень непробивного бюрократа), и потом рапортовалось ему: «мы там сервер подшаманили, всё летает» — тупо, конечно, но и волки сыты, и овцы целы.
Если бы придумать какой-нибудь универсальный общепризнанный (референсный, что-ли) метод оценки производительности, то можно и графики, и потом уже дополнительно клиента готовить к расходам на оптимизацию кода или более высокому тарифному пакету. А пока чаще бывает, что приходит клиент с говнокодом, автора которого найти не представляется возможным, и крутись как хочешь.
ls /sys/class/netlink file_name link_name
В самое яблочко!
Размер бэкапа самой системы такой маленький (~2GB), а современные носители такие большие, что ИМХО, можно не заморачиваться, и держать рядышком загрузочную копию рабочей системы, а ночью mount-rsync-umount.
А ещё можно использовать поворотный, или даже с ключом (как замок зажигания в авто) — но они по-дороже будут.