DMA да. Это пример многопоточности. Вообще, сейчас у меня состоялся дискут с коллегой, не менее глубоко разбирающимся в архитектуре процессоров. Сошлись на том, многопоточность зависит от того, к чему она применяется. И всё зависит от того, как относиться к разделению общих ресурсов. Но даже так количество потоков не может быть больше суммарного количества логических ядер ЦП внутри ЭВМ.
Так и полагал, что кто-то это напишет) Это не многопоточность, как ни странно. Ядра процессоров сидят на едином кэше третьего или второго уровня (у кого как), а доступ к этому кэшу — последователен для всех в порядке общей очереди. То же самое касается отдельных процессоров и ОЗУ. А то, что творится в рамках одного кристалла, это как исполнение макрокоманды. В общем, в этой ситуации многопоточность существует лишь на определённых уровнях приближения. Чтобы достичь настоящей многопоточности, нужно отказаться от архитектуры Фон-Неймана с её разделяемым доступом к памяти и устройствам.
А Вы, кстати, в курсе, что обращение к устройствам происходит через адресное пространство памяти? Если нет, то почитайте. Это — знатный костыль, который мы все воспринимаем как норму вещей) Последние массовые процессоры, лишённые данного костыля, были восьмибитными и имели отдельную адресную шину с сигналами переключения режимов доступа.
Пишу на C/C++. За плечами опыт ВЕБ-программиста (ещё не Frontend), когда jQuery был модным. Сбежал обратно на C/C++ от ВЕБ-а именно чтобы не иметь дела с людьми, которых описывает автор. Не считаю их идиотами или безумными фанатиками, но… Видимо мне с ними не по пути.
Конечно есть у меня и свои тараканы. Это, вообще-то, называется термином «профессиональная деформация». К примеру, привык считать программиста инженером, а инженер должен воспринимать программу не как проявление «машинного сознания» или, что ещё хуже, «магии», а как механизм. Т.е., программа — это механизм, продолжающий механизм самой электронно-вычислительной машины. Давно вы так «компьютер» называли? Очень давно? А, ведь, это — его суть.
В общем, согласен. В ВЕБ-е творится сущий фанатизм. Люди, наглухо оторванные от реальности, продолжают множить инструментарий, работающий поверх виртуальной машины. Они считают вопрос о производительности таких решений оскорбительным.
А глубинная причина лишь одна: аппаратная абстракция. Категорическое нежелание понимать машину. Плохо это? Хорошо? Да пусть пишут на этом языке, если он им так нравится) Только пусть не ведут «войну с неверными». Это как воевать за всеобщую автоматизацию, надеясь на вечную выработку электроэнергии.
JavaScript — красивый язык. Он очень демократичный и лёгкий. Почти идеальный скриптовый язык, о чём и говорит его название.
Я же предпочту знать, как работает ЭВМ, и насколько нелепыми кажутся со столь «низкого» уровня все эти танцы уверовавших в абсолютную многопоточность JS-программеров. Да-да, я знаю, как работает механизм её обеспечения, а потому знаю, что многопоточности нет. По крайней мере в рамках одной ЭВМ. Есть иллюзия.
К слову сказать, сколь бы ни были противоречивы языки go и Rast, но всё же это — попытка поиска «золотой середины». Это всё вытекает из интересов бизнеса. Заметьте! Бизнеса, а не науки. Наука преследует порядок, а бизнесу он не нужен. Ему нужен заработок. Так что, терпите. Или изобретайте альтернативу. Есть же проекты вроде LLVM.
Ну и как протокол IP может отвечать за содержимое вложенных пакетов? Этим не занимаются ни Ethernet, ни IP, ни UDP, ни TCP. А ICMP — так и вовсе сервисный протокол. Даже IPv6 не способен на такое, ведь это — всего лишь протокол! Протоколы не отвечают за анализ данных. Вселенский бред лепите!
Ребят, «визуальное позиционирование» впечатлило! Редко что вызывает такое уважение. Надеюсь, «Тындекс.Панорамы» тоже будут отрабатываться? Вы даже не в курсе, что выпуск этой штуки пополнит портфель заказов у картографов. Особенно на «технические» карты.
Мда… Не зря я покинул некогда ряды ВЕБ-программистов. Просто не выдержал бы ТАКОГО мракобесия. Даже то, что сейчас правит бал в этой сфере, побуждает рвотные позывы, что уж говорить про подобное WYSIWYG-программирование. Деградируем, товарищи, стройным шагом…
И, ведь, один фиг всё придёт к виртуальной среде исполнения, где сами ВЕБ-страницы будут считаться архаичным пережитком прошлого, а HTTP будет использоваться лишь для запуска приложений. И то ещё большой вопрос, будет ли? Но до этого обязательно надо было развести пресловутую «маслобойку»… Менеджеры… чтоб они… Впрочем, жизнь их сама накажет.
Игра — одна из моих любимых. Имеются лицензионные диски 2-ой и 3-ей версий, но запускаю «крякнутую» версию, т.к. StarForce заставлял постоянно крутить диск в приводе, что никак не добавляло комфорта игры (шумит, собака!), да и сами диски были откровенно фигового качества. От центра расползались трещины. Два диска тогда лопнули в приводах, загубив один из них. Да и «раздумья» привода приводили к притормаживаниям. Потому и «крякнул», чтоб играть с комфортом. Да и впоследствии это потребовалось, чтобы вшить патч для игры под Windows 7…
Ребят, не надо «старфорса» больше…
По поводу «мультяшной» графики — это же ПРЕВОСХОДНО!!! Это — один из факторов, делающих игру приятной и комфортной! Не надо переигрывать с остодолбавшей уже вусмерть «фотореалистичностью», она раздражает только!
По поводу «запоздавшего 3D»: А ОНО НАДО??? Вообще не понимаю, зачем в Real-Time стратегии 3D??? Оно там — лишнее… Помню, как бесил из-за этого WarCraft. 3D нужно разве что для игры в шлеме виртуальной реальности. А так это — лишь пустая трата ресурсов в игре с таким безумным количеством юнитов.
1) В моё понимание «детские компьютеры» вовсе не входит то уродство, что Вы привели в пример) Детский — значит рассчитанный по габаритам на ребёнка. Не надо гигантскую клаву, не надо высоко посаженный монитор и т.д. и т.п. Ребёнку должно быть за ним комфортно работать.
2) Под «серьёзными книгами» я подразумеваю нормальные самоучители, а не книги категории «Ты — дурак, а я — гений! Потому слушай сюда!». Это книги, имеющие в названии постфикс "… для чайников!" или "… для новичков!". Серьёзная книга поступательно учит базовым основам, но в достаточной мере, чтобы читатель после неё смог пользоваться справочником.
Вполне вероятно, что он прочитает эту книгу и сразу кинется писать простейшую программу, но захочет чего-то большего «здесь и сейчас». Есму не захочется читать «расширенное издание», а потому он возьмётся за справочник.
3) В «детские программы» я категорически не верю. Обучение методом «мартышкинских инструкций» не научит ребёнка думать своей головой. Дело, ведь, не в привыкании, а в понимании. Если ребёнок после книги начал понимать основы, он сможет понять и более сложные вещи.
Проще говоря, интерес к делу у ребёнка возбуждают осознание и успехи. Серьёзная книга объяснит на пальцах смысл и покажет на примере. Несерьёзная книга сразу выдаст готовый рецепт «на отвали».
Я, как и автор, начал программировать в 9 лет. точнее, даже в 8. Опустим тот момент, что столь выдержанный и грамотный текст статьи в те годы я написать был не в состоянии, что не мешало познавать премудрости машинной логики по советским книжкам(!), написанным для детей(!!), в которых автор относился к читателю как к себе равному(!!!), но в силу возраста многого не знающему коллеге(!!!!). Ещё могу добавить: у меня не было полноценного игрового компьютера, но простейшие игры были доступны. Когда мне не хватало чего-то в играх, отцом был запущен интерпретатор BASIC-а, а в руки дана книга для детей по программированию на нём.
К чему я это всё? Программиста нужно не только вырастить, но и воспитать. При этом, ему нельзя ничего навязывать! Впрочем, как и любому ребёнку. Достаточно всего лишь вовремя подсказывать и предупреждать. Если ребёнок упрямится и не внемлит предостережениям, то пусть наделает ошибок (если они не фатальны) — это его опыт!
Т.е., какие нужны составляющие?
1) Компьютеры для детей. Смех смехом, но это так. «Взрослый» компьютер им не удобен;
2) Серьёзные книги для детей. Это — очень важная составляющая. Да, в них должны присутствовать маскоты или просто персонажи, показывающие что-то на своём примере. Ведь сухой текст просто утомит ребёнка;
3) Мотивация. Нужны примеры, способные впечатлить, зажечь интерес. Т.е. выставки достижений, какие-то примеры программ, написанных детьми того же возраста или чуть старше. Ребёнку важно знать, что он тоже может, и это здорово.
Это потом, когда он вырастет, то узнает много подводных камней и крамол из мира программирования, но именно детские впечатления будут удерживать его интерес.
А что до общения в школе: Да, меня не могли понять. Простой код BASIC-а, написанный по памяти на тетрадном листке в клеточку вызывал недоумение у сверстников. Словно я разговаривал на чужом языке. То же самое — листинг Pascal-я в конце младшей школы и листинг Assembler-а в середине средней. Увы, никто обычно не ценит этих знаний. Не зря я упомянул выставки.
1) Тоталитаризм в отношениях «руководство-программист». У нас такого нет, и слава Богу! С начальником всегда можно нормально пообщаться, в чём-то убедить или переубедить.
2) Общение. Да мы всем коллективом собираемся у начальника, рассказываем, «кактус-пеки» (от «как успехи?»), как закончим, начинаем мозговать и обсуждать идеи. К начальнику всегда можно зайти и рассказать о задумке, поразмыслить о её востребованности.
3) Есть простыня идей — листы бумаги, куда мы пишем идеи. Иногда поднимаем, создаём собственное ТЗ и реализуем в формате «инициативного проекта» (контора у нас — подчинённая).
В принципе, нам не бывает особо скучно. Бывает трудно, долго, сложно, но чтоб скучать? А когда скучать, если задачи разные и никогда не заканчиваются?) Каждый сам выбирает, за какую задачу возьмётся. Но все считаются с очерёдностью.
У нас как раз такой проект. Медленно рефакторимся на микросервисы. Коллективный разум решил, что они создают меньше проблем, когда нужно добавить хотелку, идущую вразрез с архитектурой ПО.
Наш проект собирается пол часа. Он достался нам по наследству от коллег, которые раньше писали с применением ФП, потом сели на C++ Builder и поехали всякие TХреньКотораяДелает() --> TХреньКотораяДелаетБольше() --> TХреньКотораяДелаетМного(). Так же пошли структуры с указателями на классы для передачи данных между ними… и т.д. и т.п.
Пытаемся по немногу рефакторить сего монстра. Встаивание функционала по ТЗ (т.н. «улучшения») в код, построенный на ФП происходит раза в четыре быстрее, чем в унаследованный код. Львиную долю времени приходится отслеживать связи, чтобы понять причину падения при успешной сборке.
Да-да, архитектура, конечно, но она – наипрямейшее следствие злоупотребления ООП! И адепты ООП могут сколь угодно с пеной у рта рассказывать про «руки из жопы», но мы на этом теряем время, а потому активно выпиливаем из проекта этот зООПарк, ибо он вредит процессу.
Возможно Вы меня спутали с противником регулярок. Я их активно использую в работе. К тому же, я на C/C++ чаще работаю.
Впрочем, парсить можно и на рекурсиях с математикой вокруг кодовой таблицы символов. Но на Java из-за отсутствия прямого доступа к памяти даже это будет работать медленнее.
Если Apple выпустит автомобиль, то он будет иметь инопланетный дизайн, удобный салон с одной кнопкой и будет уметь ездить только по прямой, а поклонники Apple будут удивляться «А зачем вообще куда-то поворачивать?».
Так же, скорее всего, и тут: А зачем нам регулярки на Java? Есть и другие способы парсинга.
Возможно и так. Кстати, сам код правится через SMB-протокол прямо на виртуалках — для экономии времени и исключения лишних веток в SVN. Вот тут есть одна проблема: IDE не видят напрямую стандартные либы. Они подключаются как дополнительный каталог. Как это влияет на анализатор, трудно сказать. Он и там и там задумчив.
У нас в коллективе все используют разные IDE. Код на C++ — просто огромный. Анализатор дробит связи долго. Так вот, QtCreator тормозит существенно меньше, чем Eclipse. Это видно «невооружённым глазом». Казалось бы, нагруженный фреймворк. И обе IDE активно применяют многопоточность. Кстати, у нас Visual Studio тупит даже больше, чем Eclipse. IntelliJ IDEA тупит немного меньше, чем Eclipse, но тут сравнение проводилось на Java-коде и не столь огромном. Машины одинаковые.
Печально, что менеджмент превалирует над техническим процессом. Понимаю, «белые воротнички» хотят покупать лексусы и катать гламурных див на дискотеки с мохито… Только какое отношение всё это имеет к производству программного продукта? Вопреки мнению автора, производство – это написание и отладка программного кода. Именно это и является продуктом, а остальное – не более чем схема его реализации. И сколь бы она не влияла на продажи, она не должна оказывать влияния на программистов, т.к. от симбиоза программиста и менеджера появляются недопрограммисты-недоменеджеры. Каждый должен заниматься своим делом. И хорошо бы эти кухни окончательно разделить. Нужен продукт? Заказывайте его разработку. А что до рисков… Ну вы же сами хотели капитализм? Получите, распишитесь! Только не надо скулить о том, что «весь мир так живёт». Уже давно пора наплевать на весь мир и жить своими реалиями, которые требуют весьма жёсткого и принципиального планирования, не считающегося с рыночными «реалиями» никак.
Да я не о вариациях на эту тему… Сам принцип применения виртуальной машины для бинарного кода. Спрашивается, на кой чёрт была вся эта эволюция вычислительной мощи?
А Вы, кстати, в курсе, что обращение к устройствам происходит через адресное пространство памяти? Если нет, то почитайте. Это — знатный костыль, который мы все воспринимаем как норму вещей) Последние массовые процессоры, лишённые данного костыля, были восьмибитными и имели отдельную адресную шину с сигналами переключения режимов доступа.
Конечно есть у меня и свои тараканы. Это, вообще-то, называется термином «профессиональная деформация». К примеру, привык считать программиста инженером, а инженер должен воспринимать программу не как проявление «машинного сознания» или, что ещё хуже, «магии», а как механизм. Т.е., программа — это механизм, продолжающий механизм самой электронно-вычислительной машины. Давно вы так «компьютер» называли? Очень давно? А, ведь, это — его суть.
В общем, согласен. В ВЕБ-е творится сущий фанатизм. Люди, наглухо оторванные от реальности, продолжают множить инструментарий, работающий поверх виртуальной машины. Они считают вопрос о производительности таких решений оскорбительным.
А глубинная причина лишь одна: аппаратная абстракция. Категорическое нежелание понимать машину. Плохо это? Хорошо? Да пусть пишут на этом языке, если он им так нравится) Только пусть не ведут «войну с неверными». Это как воевать за всеобщую автоматизацию, надеясь на вечную выработку электроэнергии.
JavaScript — красивый язык. Он очень демократичный и лёгкий. Почти идеальный скриптовый язык, о чём и говорит его название.
Я же предпочту знать, как работает ЭВМ, и насколько нелепыми кажутся со столь «низкого» уровня все эти танцы уверовавших в абсолютную многопоточность JS-программеров. Да-да, я знаю, как работает механизм её обеспечения, а потому знаю, что многопоточности нет. По крайней мере в рамках одной ЭВМ. Есть иллюзия.
К слову сказать, сколь бы ни были противоречивы языки go и Rast, но всё же это — попытка поиска «золотой середины». Это всё вытекает из интересов бизнеса. Заметьте! Бизнеса, а не науки. Наука преследует порядок, а бизнесу он не нужен. Ему нужен заработок. Так что, терпите. Или изобретайте альтернативу. Есть же проекты вроде LLVM.
И, ведь, один фиг всё придёт к виртуальной среде исполнения, где сами ВЕБ-страницы будут считаться архаичным пережитком прошлого, а HTTP будет использоваться лишь для запуска приложений. И то ещё большой вопрос, будет ли? Но до этого обязательно надо было развести пресловутую «маслобойку»… Менеджеры… чтоб они… Впрочем, жизнь их сама накажет.
Игра — одна из моих любимых. Имеются лицензионные диски 2-ой и 3-ей версий, но запускаю «крякнутую» версию, т.к. StarForce заставлял постоянно крутить диск в приводе, что никак не добавляло комфорта игры (шумит, собака!), да и сами диски были откровенно фигового качества. От центра расползались трещины. Два диска тогда лопнули в приводах, загубив один из них. Да и «раздумья» привода приводили к притормаживаниям. Потому и «крякнул», чтоб играть с комфортом. Да и впоследствии это потребовалось, чтобы вшить патч для игры под Windows 7…
Ребят, не надо «старфорса» больше…
По поводу «мультяшной» графики — это же ПРЕВОСХОДНО!!! Это — один из факторов, делающих игру приятной и комфортной! Не надо переигрывать с остодолбавшей уже вусмерть «фотореалистичностью», она раздражает только!
По поводу «запоздавшего 3D»: А ОНО НАДО??? Вообще не понимаю, зачем в Real-Time стратегии 3D??? Оно там — лишнее… Помню, как бесил из-за этого WarCraft. 3D нужно разве что для игры в шлеме виртуальной реальности. А так это — лишь пустая трата ресурсов в игре с таким безумным количеством юнитов.
1) В моё понимание «детские компьютеры» вовсе не входит то уродство, что Вы привели в пример) Детский — значит рассчитанный по габаритам на ребёнка. Не надо гигантскую клаву, не надо высоко посаженный монитор и т.д. и т.п. Ребёнку должно быть за ним комфортно работать.
2) Под «серьёзными книгами» я подразумеваю нормальные самоучители, а не книги категории «Ты — дурак, а я — гений! Потому слушай сюда!». Это книги, имеющие в названии постфикс "… для чайников!" или "… для новичков!". Серьёзная книга поступательно учит базовым основам, но в достаточной мере, чтобы читатель после неё смог пользоваться справочником.
Вполне вероятно, что он прочитает эту книгу и сразу кинется писать простейшую программу, но захочет чего-то большего «здесь и сейчас». Есму не захочется читать «расширенное издание», а потому он возьмётся за справочник.
3) В «детские программы» я категорически не верю. Обучение методом «мартышкинских инструкций» не научит ребёнка думать своей головой. Дело, ведь, не в привыкании, а в понимании. Если ребёнок после книги начал понимать основы, он сможет понять и более сложные вещи.
Проще говоря, интерес к делу у ребёнка возбуждают осознание и успехи. Серьёзная книга объяснит на пальцах смысл и покажет на примере. Несерьёзная книга сразу выдаст готовый рецепт «на отвали».
К чему я это всё? Программиста нужно не только вырастить, но и воспитать. При этом, ему нельзя ничего навязывать! Впрочем, как и любому ребёнку. Достаточно всего лишь вовремя подсказывать и предупреждать. Если ребёнок упрямится и не внемлит предостережениям, то пусть наделает ошибок (если они не фатальны) — это его опыт!
Т.е., какие нужны составляющие?
1) Компьютеры для детей. Смех смехом, но это так. «Взрослый» компьютер им не удобен;
2) Серьёзные книги для детей. Это — очень важная составляющая. Да, в них должны присутствовать маскоты или просто персонажи, показывающие что-то на своём примере. Ведь сухой текст просто утомит ребёнка;
3) Мотивация. Нужны примеры, способные впечатлить, зажечь интерес. Т.е. выставки достижений, какие-то примеры программ, написанных детьми того же возраста или чуть старше. Ребёнку важно знать, что он тоже может, и это здорово.
Это потом, когда он вырастет, то узнает много подводных камней и крамол из мира программирования, но именно детские впечатления будут удерживать его интерес.
А что до общения в школе: Да, меня не могли понять. Простой код BASIC-а, написанный по памяти на тетрадном листке в клеточку вызывал недоумение у сверстников. Словно я разговаривал на чужом языке. То же самое — листинг Pascal-я в конце младшей школы и листинг Assembler-а в середине средней. Увы, никто обычно не ценит этих знаний. Не зря я упомянул выставки.
1) Тоталитаризм в отношениях «руководство-программист». У нас такого нет, и слава Богу! С начальником всегда можно нормально пообщаться, в чём-то убедить или переубедить.
2) Общение. Да мы всем коллективом собираемся у начальника, рассказываем, «кактус-пеки» (от «как успехи?»), как закончим, начинаем мозговать и обсуждать идеи. К начальнику всегда можно зайти и рассказать о задумке, поразмыслить о её востребованности.
3) Есть простыня идей — листы бумаги, куда мы пишем идеи. Иногда поднимаем, создаём собственное ТЗ и реализуем в формате «инициативного проекта» (контора у нас — подчинённая).
В принципе, нам не бывает особо скучно. Бывает трудно, долго, сложно, но чтоб скучать? А когда скучать, если задачи разные и никогда не заканчиваются?) Каждый сам выбирает, за какую задачу возьмётся. Но все считаются с очерёдностью.
Пытаемся по немногу рефакторить сего монстра. Встаивание функционала по ТЗ (т.н. «улучшения») в код, построенный на ФП происходит раза в четыре быстрее, чем в унаследованный код. Львиную долю времени приходится отслеживать связи, чтобы понять причину падения при успешной сборке.
Да-да, архитектура, конечно, но она – наипрямейшее следствие злоупотребления ООП! И адепты ООП могут сколь угодно с пеной у рта рассказывать про «руки из жопы», но мы на этом теряем время, а потому активно выпиливаем из проекта этот зООПарк, ибо он вредит процессу.
Впрочем, парсить можно и на рекурсиях с математикой вокруг кодовой таблицы символов. Но на Java из-за отсутствия прямого доступа к памяти даже это будет работать медленнее.
Если Apple выпустит автомобиль, то он будет иметь инопланетный дизайн, удобный салон с одной кнопкой и будет уметь ездить только по прямой, а поклонники Apple будут удивляться «А зачем вообще куда-то поворачивать?».
Так же, скорее всего, и тут: А зачем нам регулярки на Java? Есть и другие способы парсинга.