форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форумы Разговоры, обсуждение новостей (Public)
Изначальное сообщение		[ Отслеживать ]

"Apple выпустила диспетчер потоков Mac OS X под открытой лице..."		+/–
Сообщение от opennews (??) on 12-Сен-09, 02:01
Одним из основных нововведений (http://www.osnews.com/story/22152) очередного релиза операционной системы Mac OS X Snow Leopard  от компании Apple стала технология центральной диспетчеризации (Grand Central Dispatch), исходные коды которой выпущены под открытой лицензией Apache License v2. Библиотека не зависит от фреймворка Cocoa, написана на языке Си и должна значительно облегчить разработку программ, использующих современную многоядерную процессорную архитектуру. Технология Grand Central Dispatch — это ответ Apple на проблему параллельного программирования. С развитием современных процессоров, содержащих на одном кристалле два и более ядра, обычный домашний компьютер технологически стал похож на многопроцессорный сервер. И чтобы использовать его вычислительный ресурс на все 100% требуется каким-то образом разделить монолитную программу на ряд параллельно исполняемых независимых «нитей» (threads). Кажущаяся простота реализации этой идеи на практике даже у самых опыт... URL: http://www.osnews.com/story/22152 Новость: http://www.opennet.dev/opennews/art.shtml?num=23382
Высказать мнение | Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "Apple выпустила диспетчер потоков Mac OS X под открытой лице"		–2 +/–
Сообщение от Vital (??) on 12-Сен-09, 02:01
и в чем отличие от posix threads?
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

5. "Apple выпустила диспетчер потоков Mac OS X под открытой лице"		–1 +/–
Сообщение от ffsdmad (ok) on 12-Сен-09, 07:56
а у них не было чтоли fork? iCreateProcess ?
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

7. "Apple выпустила диспетчер потоков Mac OS X под открытой лице..."		+1 +/–
Сообщение от Юниксоид (??) on 12-Сен-09, 10:38
Unix предполагает использование множества процессов для достижения цели, ибо создание процесса в Unix очень дёшево. Поэтому мудрые программеры в случаях когда возможны описанные side effects юзают процессы, а не потоки.
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	8. "Apple выпустила диспетчер потоков Mac OS X под открытой лице..."		+/–
	Сообщение от аноним on 12-Сен-09, 11:15
	>Поэтому муд... программеры в случаях когда возможны описанные >side effects юзают процессы, а не потоки. потом всё это весело портировать
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	10. "Apple выпустила диспетчер потоков Mac OS X под открытой лице..."		+2 +/–
	Сообщение от const86 (ok) on 12-Сен-09, 11:34
	> мудрые программеры в случаях когда возможны описанные side effects юзают процессы, а не потоки. К сожалению, не все ещё достигли того уровня мудрости, когда можно наслаждаться простотой и стройностью решения с форком, глядя на потерянную производительность свысока.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	11. "Apple выпустила диспетчер потоков Mac OS X под открытой лице..."		–1 +/–
	Сообщение от Аноним (??) on 12-Сен-09, 12:04
	> глядя на потерянную производительность свысока. у Apple настолько медленное межпроцессное взаимодействие ?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	12. "Apple выпустила диспетчер потоков Mac OS X под открытой лице..."		–1 +/–
	Сообщение от letsmac on 12-Сен-09, 13:44
	Дело не в Apple - в мак оси fork работает. Просто используют поэффективнее.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	13. "Apple выпустила диспетчер потоков Mac OS X под открытой лице..."		+1 +/–
	Сообщение от xxx (??) on 12-Сен-09, 13:57
	Я далеко не гуру в вопросах многозадачности и т. п. Поэтому возможно мудрый программер Юниксоид поведает мне, как указанные side effects (имелось ввиду deadlock и race condition?) само собой обходятся при использовании процессов разделяющих одни ресурсы? Ну и ещё хотелось бы услышать пару аргументов про дешёвое создание процесса, а главное, столь же дешёвое переключение между ними.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	14. "да это просто стёб в лучшем случае"		+1 +/–
	Сообщение от Вова on 12-Сен-09, 16:14
	никакая из концепций юникс не отменяет использования многопоточности.   По теме - интересно, реализованы ли у них посиксовские политики планировки, если да - то как, лучше чем в текущем линуксе или солярисе? Для розжига любопытства добавлю, что сейчас в линуксе довольно коряво с этим, можно свободно блокировать выполнение всех процессов планирующих потоки с незаданной политикой, то есть на данный момент позволяется блокировать/деблокировать работу всех приложений, и это неверно, политики планировки потоков одного процесса не должны влиять на другие.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	24. "Apple выпустила диспетчер потоков Mac OS X под открытой лице..."		+/–
	Сообщение от pro100master (ok) on 12-Сен-09, 22:44
	>Я далеко не гуру в вопросах многозадачности и т. п. Поэтому возможно мудрый программер >Юниксоид поведает мне, как указанные side effects (имелось ввиду deadlock и race >condition?) само собой обходятся при использовании процессов разделяющих одни ресурсы? Ну >и ещё хотелось бы услышать пару аргументов про дешёвое создание процесса, а главное, столь >же дешёвое переключение между ними. в концепции TBB процессы не нужны. И грош цена им. Вообще (имхо) пора бы уже переключать логику людей с процесса на внутренности приложения. В условиях сильной конкуренции, вряд ли какой-то там конь в вакууме может лучше определить, что имели ввиду программисты приложения, и оперативно подсуетиться (опять накладные расходы), чтобы дать таблетку стероида. Тут Интел правильно мыслит.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	29. "Apple выпустила диспетчер потоков Mac OS X под открытой лице..."		–2 +/–
	Сообщение от Юниксоид (??) on 13-Сен-09, 08:58
	"I'm the first to admit that I'll probably never be able to create a correct threaded program in C++ or Java, despite years of study. It's just too hard." - Брюс Эккель, ни много ни мало. deadlock-и при многопроцессном варианте работы реализовать гораздо сложнее, чем в многопоточном. Организовать гонку тоже надо умудриться, я даже не представляю как это осуществить не через ж-пу. Когда какие-то ресурсы разделяются между процессами - это однозначно плохой дизайн. Процессы между собой должны делить только процессорное время и память, с помощью планировщика и ядра ОС соответственно. Про дешёвое создание процесса и переключение - архитектура Unix изначально под это заточена. Обо всём этом отлично описано в книге Эрика С. Реймонда "Искусство программирования для Unix", всем рекоммендую. Если не можете найти, где скачать - выложу.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	30. "ты б написал что-нить"		+/–
	Сообщение от Вова on 13-Сен-09, 10:20
	>Обо всём этом отлично описано в книге Эрика С. Реймонда "Искусство программирования >для Unix", всем рекоммендую. Если не можете найти, где скачать - >выложу.   Почитай для начала Стивенса, потом напиши пару тестовых серверов, замерь производительность с потоками и с процессами, потом перди.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	33. "ты б написал что-нить"		+/–
	Сообщение от Юниксоид (??) on 13-Сен-09, 19:51
	Некультурный вы наш ! Если цена fork имеет значение, то ваш сервер либо гифы 1х1 раздаёт, либо hello world в сокет пишет. В таком случае потоки будут заметно быстрее, само собой. Если же рабочий код выполняется продолжительное время, то доля fork будет стремиться к 0.0% Стивенс в каком месте сказал, что fork это зло ? Ткните, если не сложно. Пища для размышлений: http://www.radwin.org/michael/blog/2004/01/threads_considere... Да, писал. И с потоками в том числе. И тоже считаю, что потоки вносят чрезмерную сложность в программу.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	35. "а у нас на раёне"		+/–
	Сообщение от Вова on 13-Сен-09, 22:57
	говорят, что если цена fork не имеет значения, значит у вашего сервера загрузка в два клиента/час (4ре в час пик). Конкретнее: Стивенс, UNP, глава 23, введение и упр №1. Цитируемый вами Эккель имел в виду C++, не C, и не "С с классами", т.е. C++ без подвывертов, в котором вполне можно ещё работать. Пищу для размышлений можете в факе фидо.ру.юникс.программинг "как писать сервера" черпать, а не в жж бездельников. Мне пора, рефлексируйте.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	36. "а у нас на раёне"		+/–
	Сообщение от vitek (??) on 14-Сен-09, 09:06
	>если цена fork не имеет значения, значит у вашего сервера загрузка в два клиента/час (4ре в час пик). значит у моего сервера достаточный пул процессов и их балансировка... и хватит уже. у потоков есть свои достоинства и недостатки. допустим никто не скажет, что сервер оракл - хреновый или маленький (или что Вы там приводили?). и опять же подавляющее большинство (да все собстно!) админов скажут, что выделенный оракловый сервер (реализован через процессы) на юникс/линукс НАМНОГО лучше/быстрее/стабильнее, чем разделяемый (реализован через потоки) на винде (а там по другому и нельзя). не говоря уже о ограничениях, связанных с единым вирт. пространством, ошибками, связанными с общими ресурсами и доступом к ним, а также сложностью с управлением (планировщики ос полюбому лучше и дольше отлажываются и выполняются, чем местечковые разработки или подобные библы... тем более на какой-нибудь другой ОС и/или оборудовании (AMD?... VIA?)) зы: в результате - действительно нагруженный, сложный и мощьный сервер реализуется через процессы. что не мешает использовать потоки в некоторых, вспомогательных его частях.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	37. "а у нас на раёне"		+/–
	Сообщение от vitek (??) on 14-Сен-09, 09:10
	и ещё: >Цитируемый вами Эккель имел в виду C++, не C, и не "С с классами", т.е. C++ без подвывертов, в котором вполне можно ещё работать. забавные ограничения!!! можно подумать, что реализовать "нормальный" сервер можно только на С++! и ни-ни!!! а вот стесняюсь спросить, ассемблерные вставки тоже нельзя?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	40. "Витёк, он же Павлинукс, он же Юсер294"		–1 +/–
	Сообщение от Вова on 14-Сен-09, 11:21
	>и ещё: >>Цитируемый вами Эккель имел в виду C++, не C, и не "С с классами", т.е. C++ без подвывертов, в котором вполне можно ещё работать. > >забавные ограничения!!! >можно подумать, что реализовать "нормальный" сервер можно только на С++! >и ни-ни!!! >а вот стесняюсь спросить, ассемблерные вставки тоже нельзя? В "вашем" сервере, который существует только в вашем воображении, ассемблерные вставки не спасут орд от необходимости организации межпроцессного взаимодействия, которое ничуть и ни разу не проще взаимодействия между потоками. Займитесь чем-то полезным, любезный.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	43. "Витёк, он же Павлинукс, он же Юсер294"		+/–
	Сообщение от vitek (??) on 14-Сен-09, 19:25
	верно. но проверенных временем и разработанных лучшими специалистами по всему миру - навалом. да и ipc преподаётся во всех учебниках... и диадлоков там точно нет... а если я всё-же (!!!) умудрюсь их накодить, то пользователь сможет всё-равно им управлять (т.к. управляется системой, т.е. ОС - теже утилиты ipcrm, ipcs - набор админа) зы: >В "вашем" сервере, который существует только в вашем воображении, покажите ВАШ сервер... и мы оценим его гениальность.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	48. "а у нас на раёне"		+/–
	Сообщение от User294 (ok) on 14-Сен-09, 22:12
	>говорят, что если цена fork не имеет значения, значит у вашего сервера >загрузка в два клиента/час (4ре в час пик). Именно форк на каждое соединение клиента - на мое имхо (по итогам смотрения как это работает на практике и как соотносится с другими варантами) - та еще дурь для многих случаев. Нет, конечно, можно обслужить больше клиентов, впихав машин помощнее и побольше, побольше :).Но почему-то нагруженные сайты в последнее время предпочитают (особенно для статики) серваки на основе машин состояний :).К слову вроде в именно упомянутом факе я видел внятное описание того какие бывают вообще модели построения серверов обслуживающих много клиентов одновременно. Хотя под рукой скорее болтается http://www.kegel.com/c10k.html (у которого тоже рассказано про разные варианты построения серверов).
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	47. "ты б написал что-нить"		+/–
	Сообщение от User294 (ok) on 14-Сен-09, 21:54
	> Если цена fork имеет значение, то ваш сервер либо гифы 1х1 раздаёт, > либо hello world в сокет пишет. Наверное именно поэтому нагруженные сайты выбрасывают апач в пользу лайта и нжинкса, у которых вместо форков конечные автоматы, которые получаются сильно легче? :) Тем не менее форк - довольно интересная штука. Все-таки точная копия процесса эффективными методами - это круто и внушает. И позволяет делать ряд вкусностей крайне простыми методами скостив блочащие операции до не-блочащих. Просто данный микроскоп тоже не для любых гвоздей хорошо подходит - иногда молоток типа state machines в серваках оказывается лучше.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	49. "ты б написал что-нить"		+/–
	Сообщение от User294 (ok) on 14-Сен-09, 22:27
	>  Почитай для начала Стивенса, потом напиши пару тестовых серверов, замерь >производительность с потоками и с процессами, потом перди. А потом прикрути машины состояний и пойми что и процессы и треды запускаемые заново на каждого клиента - форменное зло? :)))
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	59. "ну как бы"		+/–
	Сообщение от Вова on 15-Сен-09, 14:11
	это был ответ на реплику о процессах, их преимуществах, о будто бы заточенной под процессы операционной системы.  Если вежливо выразить, то это просто намёк, что у Стивенса можно прочесть главу про многопоточные сетевые приложения, и там  первое упражнение - вот код, сравните производительность на вашей системе. Принимал участие в разработке двух серверов, на текущем и прошлом месте занятости, использованный шаблон у обоих был один, хоть я и не был автором ни там и не здесь - на каждого клиента нитка, и на всю систему десяток - другой ниток обработки полученных от клиентов данных, клиентские нити живут время существования соединения, обработчики живут время жизни системы. Только что смотрел систему с 500ми клиентами -полёт нормальный, 2-5 %% в top, производительности более чем хватает.  500 процессов тупо бы не влезали в top))
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	41. "Apple выпустила диспетчер потоков Mac OS X под открытой лице..."		+/–
	Сообщение от Еще один аноним on 14-Сен-09, 12:33
	> deadlock-и при многопроцессном варианте работы реализовать гораздо сложнее, чем в многопоточном. Организовать гонку тоже надо умудриться, я даже не представляю как это осуществить не через ж-пу. ... > Когда какие-то ресурсы разделяются между процессами - это однозначно плохой дизайн. Процессы между собой должны делить только процессорное время и память, с помощью планировщика и ядра ОС соответственно. Это не всегда возможно, вы про идеальное рассуждаете, как физики про идеальный газ или идеальную жидкость. Ресурсы разделяются между процессами довольно часто и это отнюдь не "однозначно плохой дизайн". Несколько процессов (или потоков, в данном случае не важно) зачастую выполняют совершенно разную работу, но при этом в разные моменты своей работы должны взаимодействовать, не только короткими сообщениями. При этом перекачивать друг другу массивы необходимых данных - непроизводительно. Очень наглядный пример - работа серверов БД. Надо по-настоящему одновременно (на многопроцессорных-то системах) обрабатывать несколько запросов от нескольких клиентов. Самое реальное решение - несколько потоков или процессов, выполняющие эту работу (даже не обязательно схема "один запрос-один процесс", можно организовывать очередь запросов к рабочим процессам). Само собой оптимальнее всего кэшировать недавно запрошенную информацию -  держать ее в оперативке. Опять же логично, что каждый процесс не будет держать свой собственный кэш - слишком накладно по памяти и страницы данных, ранее запрошенные одним процессом, могут понадобиться следующему. Следовательно кэш - общая, разделяемая между несколькими процессами область памяти, доступ к которой должен как-то регламентироваться и согласовываться. Это к вопросу о плохом дизайне параллельных систем, использующих общие ресурсы. Вот тут всплывают и понятия примитивов синхронизации - всяких семафоров, мутексов и т.п. А при ошибках программировании  и процессы запросто вогнать в дедлок - процесс A заблокировал семафор №1 и хотел было заблокировать семафор №2. Но процесс B в  этот промежуток времени успел блокировать семафор №2 и потом ему по логике надо было блокировать семафор №1, но он уже блокирован процессом A - вот и клин - каждый процесс до бесконечности ждет освобождения следующего, нужного ему семафора. Процессы и потоки абсолютно равнозначны с точки зрения опасности дедлоков, если они используют общие ресурсы. А отказаться от общих ресурсов зачастую просто невозможно - дело, как говорилось выше, не в плохом дизайне, наверное как раз наоборот - дизайн с отсутствием общих ресурсов в параллельных системах - более редкая ситуация, типа как обработка независимых кусков сцены графической картой или какой-нибудь брутфорс на тысяче компов каждый со своим проверочным диапазоном паролей :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

9. "Apple выпустила диспетчер потоков Mac OS X под открытой лице..."		–3 +/–
Сообщение от anonymous (??) on 12-Сен-09, 11:18
"дизайн GCD позволяет рабочим потокам обмениваться сообщениями не только с родительским процессом, но и между собой" Хо-хо, они придумали erlang!
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

18. "Apple выпустила диспетчер потоков Mac OS X под открытой лице..."		–1 +/–
Сообщение от pavlinux (ok) on 12-Сен-09, 19:32
> Связано это с тем, что различные «нити» требуют > доступа к одним и тем же ресурсам, причем, > зачастую одновременно. А зачем тогда распараллеливать?!
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	19. "Apple выпустила диспетчер потоков Mac OS X под открытой лице..."		+/–
	Сообщение от аноним on 12-Сен-09, 19:42
	>А зачем тогда распараллеливать?! как иначе ускорять обработку? время безумного наращивания частот и усложнения инструкций прошло
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	20. "Apple выпустила диспетчер потоков Mac OS X под открытой лице..."		–1 +/–
	Сообщение от pavlinux (ok) on 12-Сен-09, 20:12
	>>А зачем тогда распараллеливать?! > >как иначе ускорять обработку? время безумного наращивания частот > и усложнения инструкций прошло Какая разница как добираться до ресурса, через очередь или через очередь + очередь блокировок. A-поток, B-поток, ..., N-поток. R - ресурс. o - блокировка. z - разблокировка Линейно: A - o - R - z - B - o  - R - z - ... - N - o - R - z Праллел: A - B - ... N - A(o), B(o), ..., N(o), - A(R), B(R),..., N(R) - A(z), B(z),..., N(z) Причем каждый поток/процесc/задача... тусуется в очереди перед каждой блокировкой, ожидая её снятия. Так может, до 32 процессоров, выгоднее потусоваться в общей очереди?! Без блокировки: AR - BR ... - NR ------ Другое дело это параллельные вычисления. например сумма ряда, когда члены ряда считаются на отдельных процах. Sum ( sin(x)/x, от 1 до 2^64 ) на 8-ядерном CPU(1) = sin(1)/1 + sin(9)/9 +  ... CPU(2) = sin(2)/2 + sin(10)/10 + ... CPU(3) = sin(3)/3 + sin(11)/11 + ... CPU(4) = sin(4)/4 + sin(12)/12 + ... CPU(5) = sin(5)/5 + sin(13)/13 + ... CPU(6) = sin(6)/6 + sin(14)/14 + ... CPU(7) = sin(7)/7 + sin(15)/15+ ... CPU(8) = sin(8)/8 + sin(16)/16 + ...
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	21. "Apple выпустила диспетчер потоков Mac OS X под открытой лице..."		+/–
	Сообщение от агоним on 12-Сен-09, 20:38
	разве irl не будет иначе? A - B - ... - A(o) - ... - A(R) - ... - N - ... - B(o) - ... - A(z) - B(R) - ... вплоть до N-1 потоков выполняются без ожидания, полностью утилизируя мощностя
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	28. "Apple выпустила диспетчер потоков Mac OS X под открытой лице..."		+/–
	Сообщение от pavlinux (ok) on 13-Сен-09, 04:11
	>разве irl не будет иначе? >A - B - ... - A(o) - ... - A(R) - >... - N - ... - B(o) - ... - A(z) >- B(R) - ... >вплоть до N-1 потоков выполняются без ожидания, полностью утилизируя мощностя Выполняются да, без базара. Но разговор-то был про очерёдность доступа к блокируемому ресурсу. Живой пример: 1 проститутка и батальон гусар. (классика) :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	42. "Apple выпустила диспетчер потоков Mac OS X под открытой лице..."		+/–
	Сообщение от Еще один аноним on 14-Сен-09, 12:44
	>> Связано это с тем, что различные «нити» требуют >> доступа к одним и тем же ресурсам, причем, >> зачастую одновременно. > >А зачем тогда распараллеливать?! > Не, просто не все же время работы нитей - это долбежка к одному и тому же ресурсу. К ресурсу обращаемся только в отдельные моменты, причем стараемся, по возможности, чтобы на короткое время. В остальное время - обращение к другим ресурсам (часто только к своим, неразделенным) и вычисления. А всякие семафоры и мьютексы те нити в очередь и выстроят. А когда обращение к одному ресурсу тормозит всю систему из кучи нитей - вот тут уже надо что-то делать с системой или ее архитектурой - может, увеличивать кол-во ресурсов, если получится.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	46. "Apple выпустила диспетчер потоков Mac OS X под открытой лице..."		+/–
	Сообщение от letsmac on 14-Сен-09, 21:04
	>Не, просто не все же время работы нитей - это долбежка к >одному и тому же ресурсу. Естесвенно не всё. Но данные например надо кому-нибудь таки отдать, или забрать другие на обработку например - гемор с незавершёнными транзакциями, у которых надо выяснить собираются они завершаться, влияют ли на наши данные и тд ну  и например как-то сам файл с данными в случае С БД придется делить с тонной процессов через диспетчер. Особо не верящих рекомендую открыть методичку МиФи "проектирование файловых систем и БД".
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	50. "Apple выпустила диспетчер потоков Mac OS X под открытой лице..."		+/–
	Сообщение от User294 (ok) on 14-Сен-09, 22:30
	>не верящих рекомендую открыть методичку МиФи "проектирование файловых систем и БД". МиФи хороший институт, но одно все-таки не понятно: так где же отечественные файловые системы? oO
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	51. "Apple выпустила диспетчер потоков Mac OS X под открытой лице..."		+/–
	Сообщение от letsmac on 14-Сен-09, 22:38
	>>не верящих рекомендую открыть методичку МиФи "проектирование файловых систем и БД". > >МиФи хороший институт, но одно все-таки не понятно: так где же отечественные >файловые системы? oO В отечественных компах. Ну мы же знаем,  что за всем стоит user294 который даже тетрис не написал по жизни. Хотя с учетом с того что он и не читал нифига это его извиняет.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

22. "Apple выпустила диспетчер потоков Mac OS X под открытой лице"		+2 +/–
Сообщение от Erley (ok) on 12-Сен-09, 21:20
Похоже что скоро пингвины будут вынуждены портировать идеи заложенные в этом диспетчере. Многие кто тут высказывается о бесполезности такого диспетчера не совсем понимают как на практике пишутся и работают многопоточные программы. Почитайте про lock-free контейнеры, tls и попробуйте написать простенький тест чтобы убедиться, что создание процесса занимает много времени. Дальше всех в "утончении" execution path ушли микрософтовцы - у них есть сущность ещё тоньше и легче, чем поток - fiber. Правда виндовый планировщик криво ими управляет, там много вручную делать надо. Ну это как всегда у микрософта, что поделаешь... Не знаю, может в AIX и последних солярах что получше есть, не смотрел. Увеличение производительности давно связывают с более эффективным использованием нескольких процессоров. Эппл уже сейчас закладывает для этого хорошую базу (OpenCL), а не примитивные эксперименты с 1:n, n:m и прочими потоковыми библиотеками. Многое изменится в этой области в ближайшее время. И кстати не только эппловцы делают инновации в ней, что есть очень хорошо для всех нас.
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

26. "Apple выпустила диспетчер потоков Mac OS X под открытой лице..."		–1 +/–
Сообщение от kost BebiX on 13-Сен-09, 01:45
Ага. Типа "я сожру 10 минут на просчитывание нитей, зато сэкономлю тебе 10 секунд", что, впрочем, для работающих по 24 часа в сутки программ не так уж и плохо)
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

27. "Apple выпустила диспетчер потоков Mac OS X под открытой лице"		+1 +/–
Сообщение от seyko (ok) on 13-Сен-09, 03:40
Народ не прочитал новость... Смысл в получении параллельности для обычной программы. Для этого программа должна быть разбита компилятором на блоки. Поддержка всего этого включена в LLVM и clang от того же Apple. Эти блоки могут выполняться параллельно. При сборке программы компилятор делает вызовы на постановку блоков в очередь на асинхронное выполнение, из коей очереди этот самый диспетчер их и выбирает. Перед этим создав какое-то число threads для выполнения этих блоков. PS: вроде Интел тоже работает над внедрением в компиляторы автоматической разбивки программы на куски, которые могут выполняться параллеьно...
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	31. "Apple выпустила диспетчер потоков Mac OS X под открытой лице"		+/–
	Сообщение от tesseract (ok) on 13-Сен-09, 10:23
	> >PS: вроде Интел тоже работает над внедрением в компиляторы автоматической разбивки программы >на куски, которые могут выполняться параллеьно... Ну суперскалярность в процах и них есть и без хитрых компиляторов. Я так понимаю основная задача как раз научить суперскалярности менеджер потоков.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	32. "Apple выпустила диспетчер потоков Mac OS X под открытой лице"		+/–
	Сообщение от frey (ok) on 13-Сен-09, 16:00
	При чем здесь суперскалярность? Разного уровня понятия. Суть в том, о чем написано в посте на который вы отвечаете.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	34. "Apple выпустила диспетчер потоков Mac OS X под открытой лице"		+/–
	Сообщение от pro100master (ok) on 13-Сен-09, 20:52
	>При чем здесь суперскалярность? Разного уровня понятия. Суть в том, о чем >написано в посте на который вы отвечаете. при том. Вся современная компьютерная тормозня из-за непонятного нежелания инженеров делать тактовые генераторы выше 133Мгц. Тупо есть и 450Ггц проекты, а синхронизирующие генераторы даже гигагерца не осилили. Появилась суперскалярность - пока данные туда-сюда - мы выполним х-инструкций (скалярность), причем, можно невпопад (супер). Потому что продавать что-то надо. Но. Проблема в 1) дикие затраты на переключение внутри диспетчеров ОС, 2) еще более дикое усложнение программы для эффективного использования ядер (а сейчас ведь "делают ядра, а не гигагерцы"). Современные процы не утилизируют и 30% транзисторов (могу ошибаться, но за вычетом кеша, вероятно где-то так и есть). Простой пример . Core и текущие ксенонки могут выполниться 4 инструкции за такт. Но вот беда, при чтении-записи-чтении из/в память ядро может 20 тактов (до 80 инструкций) просидеть в ожидании, кода память родит хоть что-то. Переключение между процессами (ту была статья не так давно по тому же линуху) стоит от 100к до 1м тактов. В виндах еще хуже. И вот выше рассматривали потоки как они идут на более высоком уровне, где не всё так гладко, а ведь очевидно, что не учли еще и диспетчера ОС, диспетчера проца и существующий 4-6-8-12 мб кеши на проце.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	44. "Apple выпустила диспетчер потоков Mac OS X под открытой лице"		+/–
	Сообщение от pppp on 14-Сен-09, 20:08
	Вы, наверное, плохо отдаёте себе отчёт в том, что здесь совсем недалеко маячит дедушка Эйнштейн. 300 * 10^6 / 133 * 10^6 ~ 2.5 метра. Именно на такое максимальное расстояние успеет распостраниться сигнал от генеретора тактовой частоты 133МГц; причём, в вакууме. Для металлических проводников эту цифрц надо делить на 2. Добавим к этому параллельный интерфейс (т.е. необходимость синхронизации барьером) и исключение возможности "столкновения" сигналов -- получаем те же самые 133-200МГц. В последовательном интерфейсе (при условии расположения памяти не далее 10см от контроллера) можно достичь частот выше 1ГГц.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	52. "Apple выпустила диспетчер потоков Mac OS X под открытой лице"		+/–
	Сообщение от letsmac on 14-Сен-09, 22:46
	>такое максимальное расстояние успеет распостраниться сигнал от генеретора тактовой частоты 133МГц; >причём, в вакууме. Для металлических проводников эту цифрц надо делить на >2. >Добавим к этому параллельный интерфейс (т.е. необходимость синхронизации барьером) и исключение возможности >"столкновения" сигналов -- получаем те же самые 133-200МГц. "Барьер" Это строб в виду имеется? Ну даже без Энштейна повторителей никто не отменял. А ещё наводки немерянным тепловым шумом + квадратность сигнала и время на не очень полезный для здоровья транзисторов шаг накачки поля. Не от хорошей жизни это - факт. Повышение параллельности - Cell внезапно помер. А OpenCL пока рождается. Не факт что выживет.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	53. "Apple выпустила диспетчер потоков Mac OS X под открытой лице"		+/–
	Сообщение от pro100master (ok) on 14-Сен-09, 22:54
	>Вы, наверное, плохо отдаёте себе отчёт в том, что здесь совсем недалеко >маячит дедушка Эйнштейн. >300 * 10^6 / 133 * 10^6 ~ 2.5 метра. Именно на >такое максимальное расстояние успеет распостраниться сигнал от генеретора тактовой частоты 133МГц; >причём, в вакууме. Для металлических проводников эту цифрц надо делить на >2. >Добавим к этому параллельный интерфейс (т.е. необходимость синхронизации барьером) и исключение возможности >"столкновения" сигналов -- получаем те же самые 133-200МГц. В последовательном интерфейсе >(при условии расположения памяти не далее 10см от контроллера) можно достичь >частот выше 1ГГц. да, да, еще и наводки, материалы с примесями и т.д. Уже давно это один из первых аргументов. Я по первому диплому радиоинженер :))) Только вот сдаётся мне, что главная причина сугубо маржовая - никто не рискнёт сказать на рынке "баста, теперь надо скинуться в котёл и собрать 10^1.5...2 млрд и забацать прогресс". Как вы уже в курсе, народ 450Ггц преодолел. И вообще, современные сигналы вещь забавная - под калькуляцию, которую вы привели, лет 50 уже как не вмещаются :)))
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	54. "Apple выпустила диспетчер потоков Mac OS X под открытой лице"		+/–
	Сообщение от letsmac on 14-Сен-09, 23:05
	>да, да, еще и наводки, материалы с примесями и т.д. Уже давно >это один из первых аргументов. Я по первому диплому радиоинженер :))) Я типо тоже - но это было 10 лет назад. И как помню - 133 Мгц вроде как предел для традиционной электроники. 450 - это что-то уже эмпирическое. DDR само по себе интересное решение. Дальше выход в спинтронику и оптику. А про "кто-то вышел" это хрень всё - 64 килобита так никто в модемах и не преодолел - та старая теорема из учебника Баскакова непреодолима эт факт :-)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	55. "Apple выпустила диспетчер потоков Mac OS X под открытой лице"		+/–
	Сообщение от pro100master (ok) on 15-Сен-09, 00:15
	> А про "кто-то вышел" это >хрень всё - 64 килобита так никто в модемах и не >преодолел - та старая теорема из учебника Баскакова непреодолима эт факт дсл. По началу даже сопли не меняли. Что до пределов, спутниковые да и мобильники принимают себе спокойно на гигагерцовых частотах и башню им от этого не сносит :))) Предел, это когда не знаешь как и бьёшься головой об стенку ;)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	56. "Apple выпустила диспетчер потоков Mac OS X под открытой лице"		+/–
	Сообщение от User294 (ok) on 15-Сен-09, 00:46
	>  Как вы уже в курсе, народ 450Ггц преодолел Угу, только вот у CMOS (одна из наиболее энергоэффективных схемотехник известных на сегодня) есть характерное свойство: потребление равно емкости элемента схемы помноженной на частоту переключения, что, как бы очень логично выглядит с точки зрения физики. Больше частота = больше кушает, стало быть. А теперь вспоминаем что было когда интель попробовал сильно за 3 ГГц вылезти. Правильно - процы получились очень ЖРУЧИЕ. Потому что транзисторов в них - много. И они там не для украшения а чтобы переключаться. И чем больше транзюков и чем чаще они переключаются - тем больше кушается на перезаряд емкостей (кстати это позволяет снижать потребление схем снижая частоту или отключая клок совсем). А теперь угадайте, что будет на 450ГГц? Правильно - примитивная схема сможет на них работать (правда потребует дорогих компонентов, не тех которые в обычных кремниевых чипах).Но вот мало-мальски сложная схема, как то процессор тупо умрет от своего же тепла. Они и так то жрут некисло. И врядли емкости и т.п. сущности можно снизить *кардинально*. Поэтому на 450ГГц схемы делают. Тупые. Из небольшого количества элементов. А когда вы попробуете это изобразить в процессоре из сотен миллионов транзисторов, он неминуемо сдохнет от своего же тепла.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	57. "Apple выпустила диспетчер потоков Mac OS X под открытой лице"		+/–
	Сообщение от аноним on 15-Сен-09, 02:24
	>неминуемо сдохнет от своего же тепла смотря как охлаждать реально проложить внутри пластины или криотрубки
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	60. "Apple выпустила диспетчер потоков Mac OS X под открытой лице"		+/–
	Сообщение от User294 (ok) on 17-Сен-09, 01:15
	>смотря как охлаждать >реально проложить внутри пластины или криотрубки Похрену, помрет от локального перегрева - теплопроводность у полупроводников обычно так себе. Или вообще все разрушится от диких перепадов температур при потугах отводить киловатты тепла (а вы сколько хотели увидеть на такой частоте, когда процы нынче жрут до сотен ватт на их несколько ГГц?).
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	58. "Apple выпустила диспетчер потоков Mac OS X под открытой лице"		+/–
	Сообщение от pro100master (ok) on 15-Сен-09, 09:15
	>А теперь вспоминаем что было когда интель попробовал сильно за 3 ГГц >вылезти. Правильно - процы получились очень ЖРУЧИЕ. Потому что транзисторов в >них - много. И они там не для украшения а чтобы >переключаться. И чем больше транзюков и чем чаще они переключаются - >тем больше кушается на перезаряд емкостей (кстати это позволяет снижать потребление >схем снижая частоту или отключая клок совсем). А теперь угадайте, что >будет на 450ГГц? Правильно - примитивная схема сможет на них работать ну вот, опять Интел. К ним претензий нет. У них и кеш на сравнимой частоте работает. Кеш это память? Память. И вопрос я поднял о памяти. >А когда вы попробуете это изобразить в процессоре из сотен миллионов транзисторов, он неминуемо сдохнет от своего же тепла. а зачем столько? Из миллиарда транзисторов - 90% кеш, который как раз и сглаживает потери времени на операциях с памятью. Вычислительные блоки там не намного больше первых пней. Просто их количество существенно больше, опять же из-за суперскалярности. Вы забываете, что не PC единым. Я как раз согласен, что PC сам себя губит - постоянно тянуть писиай, дма и прочее дорого обходится.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Индекс форумов | Темы | Пред. тема | След. тема