DMA да. Это пример многопоточности. Вообще, сейчас у меня состоялся дискут с коллегой, не менее глубоко разбирающимся в архитектуре процессоров. Сошлись на том, многопоточность зависит от того, к чему она применяется. И всё зависит от того, как относиться к разделению общих ресурсов. Но даже так количество потоков не может быть больше суммарного количества логических ядер ЦП внутри ЭВМ.
Так и полагал, что кто-то это напишет) Это не многопоточность, как ни странно. Ядра процессоров сидят на едином кэше третьего или второго уровня (у кого как), а доступ к этому кэшу — последователен для всех в порядке общей очереди. То же самое касается отдельных процессоров и ОЗУ. А то, что творится в рамках одного кристалла, это как исполнение макрокоманды. В общем, в этой ситуации многопоточность существует лишь на определённых уровнях приближения. Чтобы достичь настоящей многопоточности, нужно отказаться от архитектуры Фон-Неймана с её разделяемым доступом к памяти и устройствам.
А Вы, кстати, в курсе, что обращение к устройствам происходит через адресное пространство памяти? Если нет, то почитайте. Это — знатный костыль, который мы все воспринимаем как норму вещей) Последние массовые процессоры, лишённые данного костыля, были восьмибитными и имели отдельную адресную шину с сигналами переключения режимов доступа.
Пишу на C/C++. За плечами опыт ВЕБ-программиста (ещё не Frontend), когда jQuery был модным. Сбежал обратно на C/C++ от ВЕБ-а именно чтобы не иметь дела с людьми, которых описывает автор. Не считаю их идиотами или безумными фанатиками, но… Видимо мне с ними не по пути.
Конечно есть у меня и свои тараканы. Это, вообще-то, называется термином «профессиональная деформация». К примеру, привык считать программиста инженером, а инженер должен воспринимать программу не как проявление «машинного сознания» или, что ещё хуже, «магии», а как механизм. Т.е., программа — это механизм, продолжающий механизм самой электронно-вычислительной машины. Давно вы так «компьютер» называли? Очень давно? А, ведь, это — его суть.
В общем, согласен. В ВЕБ-е творится сущий фанатизм. Люди, наглухо оторванные от реальности, продолжают множить инструментарий, работающий поверх виртуальной машины. Они считают вопрос о производительности таких решений оскорбительным.
А глубинная причина лишь одна: аппаратная абстракция. Категорическое нежелание понимать машину. Плохо это? Хорошо? Да пусть пишут на этом языке, если он им так нравится) Только пусть не ведут «войну с неверными». Это как воевать за всеобщую автоматизацию, надеясь на вечную выработку электроэнергии.
JavaScript — красивый язык. Он очень демократичный и лёгкий. Почти идеальный скриптовый язык, о чём и говорит его название.
Я же предпочту знать, как работает ЭВМ, и насколько нелепыми кажутся со столь «низкого» уровня все эти танцы уверовавших в абсолютную многопоточность JS-программеров. Да-да, я знаю, как работает механизм её обеспечения, а потому знаю, что многопоточности нет. По крайней мере в рамках одной ЭВМ. Есть иллюзия.
К слову сказать, сколь бы ни были противоречивы языки go и Rast, но всё же это — попытка поиска «золотой середины». Это всё вытекает из интересов бизнеса. Заметьте! Бизнеса, а не науки. Наука преследует порядок, а бизнесу он не нужен. Ему нужен заработок. Так что, терпите. Или изобретайте альтернативу. Есть же проекты вроде LLVM.
Ну и как протокол IP может отвечать за содержимое вложенных пакетов? Этим не занимаются ни Ethernet, ни IP, ни UDP, ни TCP. А ICMP — так и вовсе сервисный протокол. Даже IPv6 не способен на такое, ведь это — всего лишь протокол! Протоколы не отвечают за анализ данных. Вселенский бред лепите!
Ребят, «визуальное позиционирование» впечатлило! Редко что вызывает такое уважение. Надеюсь, «Тындекс.Панорамы» тоже будут отрабатываться? Вы даже не в курсе, что выпуск этой штуки пополнит портфель заказов у картографов. Особенно на «технические» карты.
Мда… Не зря я покинул некогда ряды ВЕБ-программистов. Просто не выдержал бы ТАКОГО мракобесия. Даже то, что сейчас правит бал в этой сфере, побуждает рвотные позывы, что уж говорить про подобное WYSIWYG-программирование. Деградируем, товарищи, стройным шагом…
И, ведь, один фиг всё придёт к виртуальной среде исполнения, где сами ВЕБ-страницы будут считаться архаичным пережитком прошлого, а HTTP будет использоваться лишь для запуска приложений. И то ещё большой вопрос, будет ли? Но до этого обязательно надо было развести пресловутую «маслобойку»… Менеджеры… чтоб они… Впрочем, жизнь их сама накажет.
Вы молодец! Куда ж нам всем без великих костылей-то?))) Надо больше несуразных решений и дилетантских советов…
Если иначе не обойтись, то в ряде случаев автору проще использовать платный русский прокси-сервер с поддержкой SOCKS 5 на путешествующем компе. А ребут, ежели случайно он потребуется, сделает watchdog в дата-центре, где расположен сервер прокси-сервиса, работающий под управлением UNIX-like ОС, которые вообще без серьёзных на то оснований перезагрузки не требуют.
Ежели вдруг рабочие софтины наотрез не понимают проксей, возможно воспользоваться тем же VPN, который, между прочим, имеется как доп.услуга у сервиса TeamViewer. Только зачем? Есть пусть и платные, зато стабильно действующие сервисы VPN-доступа к региональному сегменту Сети.
Игра — одна из моих любимых. Имеются лицензионные диски 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 будет использоваться лишь для запуска приложений. И то ещё большой вопрос, будет ли? Но до этого обязательно надо было развести пресловутую «маслобойку»… Менеджеры… чтоб они… Впрочем, жизнь их сама накажет.
Если иначе не обойтись, то в ряде случаев автору проще использовать платный русский прокси-сервер с поддержкой SOCKS 5 на путешествующем компе. А ребут, ежели случайно он потребуется, сделает watchdog в дата-центре, где расположен сервер прокси-сервиса, работающий под управлением UNIX-like ОС, которые вообще без серьёзных на то оснований перезагрузки не требуют.
Ежели вдруг рабочие софтины наотрез не понимают проксей, возможно воспользоваться тем же VPN, который, между прочим, имеется как доп.услуга у сервиса TeamViewer. Только зачем? Есть пусть и платные, зато стабильно действующие сервисы VPN-доступа к региональному сегменту Сети.
Игра — одна из моих любимых. Имеются лицензионные диски 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? Есть и другие способы парсинга.