Процессы снимают проблему со стеками и со сборкой мусора, вполне естественным образом: стеки различны, а при завершении процесса все занимаемые ресурсы можно освободить. - quite right, but: Q: что такое "процесс" в современных осях? A: "Процесс есть субъект владения... Процесс владеет памятью, дескрипторами файлов, цепочками, загруженными модулями..." (Мэт Питрек) В современных осях на х86 процесс - объект сугубо высокоуровневый (ибо аппаратно такого понятия нет) и инкапсулирует в себе всю сущность логически (человеком) выделяемой прикладной задачи.
Если в современных осях распаралеливать на уровне процессов, то нужно организовывать межпроцессное взаимодействие. Если дорастить и окультурить этот механизм, то "процессы" становятся нитями, нити "поднитями" и т.п. И так бесконечно.
Как ни назови поток - суть его одна. Поток - это фрагмент кода, выполняющийся параллельно с себеподобными в контексте одной прикладной задачи. Вот что IMHO есть поток для прикладника. И ему, если чесно, насрать на количество ядер и наноразмеры.
На ненормальных, то есть, производных от x86, проблема решается через хитрые кэши первого уровня.
Вроде бы все здесь согласны, что современная аппаратная база от Intel'а не в состоянии путёво реализовать эту задачу. Програмное распараллеливание при наличии многих аппаратных ядер IMHO есть латание дыр и атавизм. Это скоро (надеюсь) уйдет.
а сейчас мне всё-равно. К счастью, я все дальше отхожу от таких "низкоуровневых" занятий, как управление потоками иже с ним. Искренне надеюсь уйти вовсе |)
В общем то все верно, ЯВУ должны прозрачно инкапсулировать работу с потоками, и тогда будет на счастье Здесь, кстати, вспоминается долготянувшийся переход на (Win)32. Вплоть, наверное, до 2000 г. сталкивался с серьезными программами, все еще в 16bit-режиме.
Так и сейчас - два(четыре) ядра, регистры 64bit, а у нас софт под i486 скомпилирован..
Я считаю, что интел должны (и сделают) аппаратное "высокоуровневое" управление потоками. Это, безусловно, скорее в помощь системщикам, нежели прикладникам, но это даст возможность создать единый механизм управления потоками во всех осях, и вот тогда это можно встраивать в язык. Не в библиотеку, а именно на уровне языка. И тогда код вида {i+=d, j+=getInput();} действительно будет выполняться параллельно. Ну и, естественно, запись вида class CMyUsefulJob :public CThead { будет инструктировать компилятор выносить код данного класса в отдельный поток.
во-во. Только уже не кремния, а углерода. Один мой знакомый, серьезно занятый в "железной" индустрии еще годе в 2001-м вещал мне о пределе в 3-3.5 МГ и о грядущей многоядерности. Так что КорДуо у нас не от жизни хорошей (у Intel'a :)
ну гугл может и придавят, когда зажрется, а в целом от геопривязки IMHO уже не освободится. Скорее наоборот, с каждым годом ситуация будет только ухудшаться.
ты, прав, конечно, это лишь одно из проявлений. При любом роде занятий такое бывает. Но почти любой другой род занятий предполагает довольно много общения с людьми в процессе работы (общение - это когда собеседник перед тобой, а не за 127км проводов). А кодинг и пидалинг оного не предполагают. Это и есть жопа (в смысле имено отсюда ноги растут :)
да, у меня (с женой) тоже случаются такие периоды. Иногда надо просто заставить себя отвлечься - с женой, и желательно с друзьями сходить куда нибуть (в то же кино), просто ночью по парку погулять и т.п. хотя бы раз в неделю.
ЗЫ. Еще заметил одну весчь: если на работе аврал уже неделю и еще столько же предвидится - не бойся пару раз уйди с работы раньше (ну то есть вовремя :) - в работе это ничего не изменит, но легкий похуi3м полностью разгружает мозг.
ну видно по человеку, что он очень одинок в жизни, и, самое страшное, он не знает как это исправить. (Больше одиночества -> больше времени -> больше компов -> больше одиночества). Да и внешний вид сильно оставляет желать лучшего (комп же его не видит...)
Если в современных осях распаралеливать на уровне процессов, то нужно организовывать межпроцессное взаимодействие. Если дорастить и окультурить этот механизм, то "процессы" становятся нитями, нити "поднитями" и т.п. И так бесконечно.
Как ни назови поток - суть его одна. Поток - это фрагмент кода, выполняющийся параллельно с себеподобными в контексте одной прикладной задачи. Вот что IMHO есть поток для прикладника. И ему, если чесно, насрать на количество ядер и наноразмеры.
На ненормальных, то есть, производных от x86, проблема решается через хитрые кэши первого уровня.
Вроде бы все здесь согласны, что современная аппаратная база от Intel'а не в состоянии путёво реализовать эту задачу. Програмное распараллеливание при наличии многих аппаратных ядер IMHO есть латание дыр и атавизм. Это скоро (надеюсь) уйдет.
(: ...... ): /* смотря с какой стороны смотреть :) */
Так и сейчас - два(четыре) ядра, регистры 64bit, а у нас софт под i486 скомпилирован..
Я считаю, что интел должны (и сделают) аппаратное "высокоуровневое" управление потоками. Это, безусловно, скорее в помощь системщикам, нежели прикладникам, но это даст возможность создать единый механизм управления потоками во всех осях, и вот тогда это можно встраивать в язык. Не в библиотеку, а именно на уровне языка. И тогда код вида {i+=d, j+=getInput();} действительно будет выполняться параллельно. Ну и, естественно, запись вида class CMyUsefulJob :public CThead { будет инструктировать компилятор выносить код данного класса в отдельный поток.
ЗЫ. Еще заметил одну весчь: если на работе аврал уже неделю и еще столько же предвидится - не бойся пару раз уйди с работы раньше (ну то есть вовремя :) - в работе это ничего не изменит, но легкий похуi3м полностью разгружает мозг.