Высокий/низкий уровень, ручное/автоматическое управление

← →
oxffff © (2010-11-11 14:54) [160]

> tesseract © (11.11.10 14:36) [158]
>
> > А это время.
>
>
> Сборка мусора навряд ли займёт время больше свалки / загрузки
> выгружаемой памяти процесса по нужде системы.

А это уж совсем быстро. Пару тактов. :)

← →
tesseract © (2010-11-11 15:05) [161]

> А это уж совсем быстро. Пару тактов. :)

Может все таки пару-десяток сотен? А сама вот оптимизация кучи в случае двухпроцессорной машинки вообще может тактов не занять. Т.к. коллектор носится в соседнем потоке.

← →
euru © (2010-11-11 15:06) [162]

> oxffff © (11.11.10 14:22) [152]
> Я выше написал. :)

a := nil; - этот?
И каково должно быть дальнейшее поведение программы/среды выполнения после этого выражения?

← →
tesseract © (2010-11-11 15:07) [163]

Кстати вот офф рекомендации от Apple. http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/GarbageCollection/Articles/gcAdoption.html#//apple_ref/doc/uid/TP40002457

Собственно почти все недостатки описаны замечательно.

← →
oxffff © (2010-11-11 15:11) [164]

> tesseract © (11.11.10 15:05) [161]
>
> > А это уж совсем быстро. Пару тактов. :)
>
>
> Может все таки пару-десяток сотен? А сама вот оптимизация
> кучи в случае двухпроцессорной машинки вообще может тактов
> не занять. Т.к. коллектор носится в соседнем потоке.

Коллектор не может нестить в другом процессе сам по себе. Поскольку куча разделяемая. Тормозятся все потоки управляемого кода.

← →
DiamondShark © (2010-11-11 15:11) [165]

Я сейчас пишу под мобильные девайсы на NET-Compact. Девайсы довольно хиленькие, как по процессору, так и по объёмам памяти. Если верить профилировщику, то мусорщик ходит не часто, а весьма часто. Каких-нибудь неудобств в связи с этим не заметно вообще.

Так что опасения про время сборки мусора считаю сильно преувеличенными.

Теперь другой момент.
Тот проект, что я пишу, раньше вёлся (другими людьми) на нативном С++. Он не был завершён, потому что упёрся в две вещи:
- в сложность
- в, таки да, дефицит памяти.
К моменту смерти проекту исполнилось два года.

Чуть более, чем за пол-года я не только переписал его с нуля до уровня коммерческого внедрения, но и вижу неплохие перспективы развития. А пределов ресурсов платформы -- наоборот, даже и на горизонте не вижу.

Я не фанат шарпа и не считаю дотНЕТ идеалом менеджед-сред, но, пользуясь случаем, хочу передать превед любителям С++.

ЗЫ
Разумеется, я знаю, что то были неправильные программисты на С++.

← →
oxffff © (2010-11-11 15:12) [166]

> euru © (11.11.10 15:06) [162]
>
> > oxffff © (11.11.10 14:22) [152]
> > Я выше написал. :)
>
> a := nil; - этот?
> И каково должно быть дальнейшее поведение программы/среды
> выполнения после этого выражения?

А если a:ISomeStuff?

← →
oxffff © (2010-11-11 15:14) [167]

> Коллектор не может нестить в другом процессе сам

Потоке естественно.

← →
DiamondShark © (2010-11-11 15:18) [168]

> У меня это Windows. Я бы с удовольствие в данный момент
> использовал гибридный способ. Есть у меня такая сейчас задача.

Так и у меня пока что это Windows. Только подход прямо противоположный: ручное управление ТОЛЬКО при интеропе с неуправляемым окружением, потому что "куды ты денешься с подводной лодки".

Интересует обоснование ручного управления именно в менеджед-окружении. А этого я пока не увидел.

← →
euru © (2010-11-11 15:27) [169]

> oxffff © (11.11.10 15:12) [166]
> А если a:ISomeStuff?

Допустим. Т.е. имеем:
a: ISomeStuff . . . // код, использующий a a := nil; . . . // продолжение программы
Что должно произойти после a := nil;?

← →
oxffff © (2010-11-11 15:30) [170]

> DiamondShark © (11.11.10 15:18) [168]
>
> > У меня это Windows. Я бы с удовольствие в данный момент
>
> > использовал гибридный способ. Есть у меня такая сейчас
> задача.
>
> Так и у меня пока что это Windows. Только подход прямо противоположный:
> ручное управление ТОЛЬКО при интеропе с неуправляемым окружением,
> потому что "куды ты денешься с подводной лодки".
>
> Интересует обоснование ручного управления именно в менеджед-
> окружении. А этого я пока не увидел.

Кого интересует? Меня? Совершенно не интересует. У меня native код.
Я собственнно все о том примере.

← →
oxffff © (2010-11-11 15:34) [171]

> euru © (11.11.10 15:27) [169]
>
> > oxffff © (11.11.10 15:12) [166]
> > А если a:ISomeStuff?
>
> Допустим. Т.е. имеем:
> a: ISomeStuff
> . . . // код, использующий a
> a := nil;
> . . . // продолжение программы
>
> Что должно произойти после a := nil;?

Ничего. На a ссылаются еще два корня. Как только завершат заботу потоки и управляемые параметры финазируются объект финализируется и деаллокируется. Только правильно это сделать "защищенно".

← →
tesseract © (2010-11-11 15:51) [172]

> Если верить профилировщику, то мусорщик ходит не часто,
> а весьма часто. Каких-нибудь неудобств в связи с этим не
> заметно вообще.

Я помню только один недостаток WinCe с которым работал - там память была медленная независимо от того родной там код или управляемый, и она кончалась моментально. Но это было ещё 4.1 где механизмы радикально отличались от 5 и выше.

← →
DiamondShark © (2010-11-11 15:56) [173]

> Mystic © (11.11.10 14:34) [157]
> Что в свою очередь увеличит время компиляции, усложнит уровень
> вхождения в язык (надо будет разбираться со всей этой кухней
> чтобы управлять этим), и приведет к разным хитрым багам/фичам
> + добавит радости в отладке.

Про время компиляции, уровень вхождения и радость в отладке вы уже сейчас можете побеседовать с программистами на С++, юзающими какую-нибудь библиотеку с шаблонами.
А ещё лучше примите такой проект на сопровождение. ;)

Почему-то, когда хвастаются глубокой оптимизацией в Си-компиляторах и фичами библиотек шаблонов, то это типа круто.
А в другие языки фичи нельзя добавлять, потому что время компиляции.

Не чувствуете тут фигни с логикой?

> Такое дополнительное декларирование это тоже дополнительная
> работа. Может оказаться, что ручками распараллелить критичный
> кусок будет быстрее, чем по всему проекту поддерживать инварианты.

Ручками не получится быстрее, потому что ручками придётся писать кучу инфраструктурного кода.

> Во-вторых, есть случаи, когда такие инварианты доступны
> только через обращение к чему-то внешнему, вроде базы данных,
> DLL, ... В этом случае компилятор никак не сможет проверить
> инвариантность,

DLL быть не должно. Для управляемых модулей доступна вся метаинформация.
А если компилятор что-то не сможет формально проверить, то просто не будет генерировать параллельный код.

> посему надо будет писать в коде "мамой клянусь!
> ". Что опять может породить интересные баги.

Буквально пару предложений выше вас не смущала необходимость ручками написать "мамой клянусь!" с возможностью багов, более того, вы пытаетесь доказать что иной способ не нужен.

Возражая мне, не противоречьте сами себе. Хотябы в пределах абзаца ;)

> Нет, за динамической памятью надо следить, потому что стоит
> задача максимально полно и эффективно использовать ограниченный
> объем памяти.

Я про разработку на девайсах уже написал. Там с памятью вообще очень грустно всё.

Это всё предрассудки, боязнь мнимой потери контроля.

> Но в целом это задача, где возможностей C хватает и в чем-
> то большем большой нужды нет.

Ну так значит ваша задача к сравнению возможностей языков не имеет отношения никакого. С -- примитивный язык.

← →
crux (2010-11-11 16:04) [174]

oxffff © (11.11.10 12:51) [147]

>Поэтому мне интересен гибридный способ управления.

По крайней мере в Managed C++ (до того, как он стал C++/CLI) была возможность совмещать мусорособираемые объекты .NET с нативными (через нестандартный синтаксис). Осталось ли эта возможность сейчас, не уверен (похоже, что осталась, убирать ее было бы не логично).

← →
tesseract © (2010-11-11 16:06) [175]

> С -- примитивный язык.

Нормальный он язык. И для определенных целей - например консольных приложений он лучше огорода ООП.

> Ручками не получится быстрее, потому что ручками придётся
> писать кучу инфраструктурного кода.

Хорошо приучает к экономии идентификаторов и запихивании логики по функциям кстати. Но это уже другая история.

← →
oxffff © (2010-11-11 16:10) [176]

> crux (11.11.10 16:04) [174]
> oxffff © (11.11.10 12:51) [147]
>
> >Поэтому мне интересен гибридный способ управления.
>
> По крайней мере в Managed C++ (до того, как он стал C++/CLI)
> была возможность совмещать мусорособираемые объекты .NET
> с нативными (через нестандартный синтаксис). Осталось ли
> эта возможность сейчас, не уверен (похоже, что осталась,
> убирать ее было бы не логично).

Она никуда не делать. Это называется pinned оbject.
Сборщику запрещено перемещать объект в куче.

← →
euru © (2010-11-11 16:27) [177]

> oxffff © (11.11.10 15:34) [171]
> Ничего.

Т.е. это просто декларация компилятору, что как только все остальные также перестанут ссылаться на этот элемент, то его можно смело удалять из кучи? Ну так при анализе кода компилятор и сам может об этом догадаться и пометить данную ссылку неактивной. А если компилятор этого делать не умеет, а программист, в свою очередь, не продекларирует, то мы получим утечку памяти.

> На a ссылаются еще два корня.

Это только в том случае, если у обеих процедур DoInvarian1 и DoInvariant2 описание параметров выглядит как (var b: ISomeStuff). В противном случае переменная a и параметры процедур независимо друг от друга ссылаются на один и тот же объект в памяти.

> Как только завершат
> заботу потоки и управляемые параметры финазируются объект
> финализируется и деаллокируется. Только правильно это сделать
> "защищенно".

Эти потоки могут, в свою очередь, создать другие потоки, также использующие данный параметр. Так что завершение этих потоков не гарантирует освобождение всех ссылок на объект в памяти.

← →
Дмитрий Белькевич (2010-11-11 16:27) [178]

> Разумеется, я знаю, что то были неправильные программисты
> на С++.

"К свойствам языков эта кухонная статистика вообще не имеет никакого отношения."

← →
Дмитрий Белькевич (2010-11-11 16:32) [179]

> и радость в отладке

Расскажу про свою. Как-то либу пытался отлаживать. Модулей под тысячу. На каждый пук - класс. На каждый класс - модуль+хидер.
Пришлось таки человека нанимать. Ну не моё это :)
Человек переписали на делфю. На делфе - 5 модулей. Функциональность - в 5 раз больше. Код можно охватить одним мозгом :)

И, да, "К свойствам языков эта кухонная статистика вообще не имеет никакого отношения."

← →
Дмитрий Белькевич (2010-11-11 16:33) [180]

Но осадочек остался :)

← →
Mystic © (2010-11-11 17:12) [181]

> Про время компиляции, уровень вхождения и радость в отладке
> вы уже сейчас можете побеседовать с программистами на С++,
> юзающими какую-нибудь библиотеку с шаблонами.
> А ещё лучше примите такой проект на сопровождение. ;)

Шаблоны C++ это верх идеи о том, что все должно быть автоматизировано компилятором. Соответственно, в результате имеем определенный геморрой. Мне больше нравятся простые языки, тот же C например.

> Ручками не получится быстрее, потому что ручками придётся
> писать кучу инфраструктурного кода.

Я не утверждал на 100%. Но сравнительно часто инфраструктурного кода оказывается не так уж и много, написал да забыл :)

> DLL быть не должно.

Под Windows все конечном итоге все сводится к вызовам DLL. Но лучше подождем, когда такие возможность появится, пока что мы обсуждаем то, чего нет и близко.

> Я про разработку на девайсах уже написал. Там с памятью
> вообще очень грустно всё.

А я где-то писал, что мало памяти? Мало память, маленькая куча, ею легко управлять :) Тут наоборот, у движка солидный хэш, (например, 512M или 1G), который надо эффективно использовать. Если брать чисто генерацию ходов, то современные движки прекрасно выжимают 1 000 000 (=1M) позиций в секунду. Допустим, одна позиция это 128 байт данных, итого получает 128M секунду, таким образом наш хэш заполнится за пять секунд. После этого я, допустим, нашел еще 2.5M неактуальных позиций и очистил ссылки на них. После чего должен запуститься сборщик мусора, который должен проанализировать все наши 5M объектов в памяти, чтобы найти 2.5M объектов, к которым нельзя добраться по ссылкам...

> С -- примитивный язык.

И в этом его недостаток, но и его преимущество.

← →
DiamondShark © (2010-11-11 17:26) [182]

> tesseract © (11.11.10 16:06) [175]
>> С -- примитивный язык.
> Нормальный он язык. И для определенных
> целей - например консольных приложений он лучше огорода
> ООП.

Вы не обижайтесь так, "примитивный" -- это не ругательство, это термин.
Вот Int, например -- примитивный тип. Вы ж не возразите, что он нормальный тип. ;)

>> Ручками не получится быстрее, потому что ручками
>> придётся писать кучу инфраструктурного кода.
> Хорошо приучает
> к экономии идентификаторов и запихивании логики по функциям
> кстати. Но это уже другая история.

Фигасе. Идентификаторы -- это уже ресурс, который надо экономить? %(

А логика должна не "запихиваться" (с оглядкой, блин, на экономию идентификаторов), а проектироваться. Желательно, чтобы этому процессу ничего (вроде БДСМ-ных замашек языка, который "приучает") не мешало.

← →
tesseract © (2010-11-11 17:47) [183]

> Вы не обижайтесь так, "примитивный" -- это не ругательство,
> это термин.

Я не обижаюсь. Собственно Си начал осваивать когда баловался с *nix и OS-софтом. Читабельность кода у него распологает.

> Фигасе. Идентификаторы -- это уже ресурс, который надо экономить?
> %(

Если не любишь того, кто твой код поддерживать будет можешь не экономить. Лучше не распалятся :-)

> Желательно, чтобы этому процессу ничего (вроде БДСМ-ных
> замашек языка, который "приучает") не мешало.

Это к любому языку относится. BSDM-ные замашки на паскале встречаются повсеместно, не смотря на его вроде-как логичность.

← →
DiamondShark © (2010-11-11 17:54) [184]

> Mystic © (11.11.10 17:12) [181]
> Шаблоны C++ это верх идеи о том, что все должно быть автоматизировано
> компилятором. Соответственно, в результате имеем определенный
> геморрой.

Я выше писал, что как генератор идей C++ весьма очень даже.
Сама идея шаблонов, параметризованного кода, обобщённого программирования -- хороша есть весьма.
Реализация -- ни к чёрту.

Плюсные шаблоны вообще нельзя реюзать иначе, как в виде исходного кода. Отсюда и все прелести со скоростью компиляции и радостью в отладке.

А теперь ищем чуть выше ссылку на Франца, и видим, что для той технологии шаблоны -- как родные.

> Под Windows все конечном итоге все сводится к вызовам DLL.
> Но лучше подождем, когда такие возможность появится, пока
> что мы обсуждаем то, чего нет и близко.

Я и хотел пообсуждать то, чего пока нет.

> После чего должен запуститься сборщик мусора, который должен
> проанализировать все наши 5M объектов в памяти, чтобы найти
> 2.5M объектов, к которым нельзя добраться по ссылкам...

Это очень быстро. Медленнее, чем в Дельфи, но вы выиграете на времени выделения. В среднем не будет большой разницы.
Где-то были бенчмарки по работе с памятью. Можно поискать.
Результаты, если правильно помню, такие: самая тормознутая -- стандартная С-библиотека, самая шустрая дельфийская ФастММ. ДотНЕТ где-то посередине ПО СРЕДНЕМУ времени.

Да и дотнетовский менеджер не самый оптимальный по скорости из возможных алгоритмов автоматических менеджеров. Что и не скрывалось никогда.

← →
tesseract © (2010-11-11 18:02) [185]

> Сама идея шаблонов, параметризованного кода, обобщённого
> программирования -- хороша есть весьма.

Посмотри smalltalk. Почитал синию книжку - вот где кладезь идей был. В 1972 ! Все обобщено и без лишних костылей.

← →
Mystic © (2010-11-11 18:33) [186]

> Я выше писал, что как генератор идей C++ весьма очень даже.
>
> Сама идея шаблонов, параметризованного кода, обобщённого
> программирования -- хороша есть весьма.

В данном случае идея стырена из ады. И адский подход мне нравится куда больше, ибо в нем больше строгости. По крайней мере всяких валидольных ошибок с кишками нету :)

generic type Element is private; package Stacks is procedure Push(E : in Element); procedure Pop(E : out Element); function Empty return Boolean; private The_Stack : array(1..200) of Element; top : Integer range 0..200 := 0; end Stacks;

> Я и хотел пообсуждать то, чего пока нет.

А смысл? У меня даже нет никаких идей по реализации таких систем. Нет, у меня хватит фантазии преставить систему, на вход которой подается T3 на естественном языке, а на выходе получаем программу. Но принципы ее фунционирования для меня загадка. Так и тут, я конечно могу представить, что есть система, которая берет текст на C# и параллелит его автоматом. Но на этом пути я вижу пока что кучу проблем, и считаю его нереальным.

А вот адский подход к многозадачности, уже 25 лет как реализованый:

with Ada.Text_IO; procedure Multitasking_Demo is -- спецификация анонимной задачи task Anonimous_Task; -- тело анонимной задачи task body Anonimous_Task is begin -- для Anonimous_Task for Count in 1..5 loop Ada.Text_IO.Put_Line("Hello from Anonimous_Task"); end loop; end Anonimous_Task; -- спецификация типа задачи task type Simple_Task (Message: Character); -- тип задачи имеет тело task body Simple_Task is begin -- для Simple_Task for Count in 1..5 loop Ada.Text_IO.Put_Line("Hello from Simple_Task " & Message); end loop; end Simple_Task; -- переменная задачного типа Simple_Task_Variable: Simple_Task(Message => "A"); begin -- для Multitasking_Demo -- в отличие от процедур, задачи не вызываются, -- а активируются автоматически -- выполнение обоих задач начинается как только -- управление достигнет этой точки, то есть, сразу -- после "begin", но перед выполнением первой инструкции -- головной процедуры Multitasking_Demo null; end Multitasking_Demo;

Кстати, иногда хочется побыть в альтернативной реальности, где Borland вы выбрал вместо паскаля аду :)

> Это очень быстро. Медленнее, чем в Дельфи, но вы выиграете
> на времени выделения. В среднем не будет большой разницы.
>
> Где-то были бенчмарки по работе с памятью. Можно поискать.

Смысл искать, если объекты имеют одинаковый размер? Соответственно эффективный менеджер памяти пишется за 15 минут: все свободные объекты поместили в список. Нужен новый объект --- взяли его из списка. Не нужен --- поместили обратно :)

← →
DiamondShark © (2010-11-11 19:52) [187]

> В данном случае идея стырена из ады.

Да не важно, откуда она стырена. Я ж говорю: С++ -- это как заповедник.

> Нет, у меня хватит фантазии преставить систему

Что вы, я маниловщину и не предлагаю.

> Так и тут, я конечно могу представить, что есть система,
> которая берет текст на C# и параллелит его автоматом. Но
> на этом пути я вижу пока что кучу проблем, и считаю его
> нереальным.

Похожее умел ещё Турбо-Паскаль 5.5. Он старался сгенерировать код, максимально использующий возможность параллельной работы CPU и FPU. Чем не прообраз многоядерного параллелизма?

Сейчас вот интел изобретает примочку в процессор, для анализа непосредственно потока команд и раскидывания по ядрам. Видимо, решил не ждать милостей от разработчиков компиляторов %(

Подчеркну, что я не многозадачность говорю, а именно про внутренний параллелизм. Что-то типа такого:
a := (X + Y) * (U - V);
Подвыражения "(X + Y)" и "(U - V)" можно вычислить на разных ядрах параллельно.
Это могут быть не только сложные выражения, но и, скажем, разные участки линейной последовательности операторов. Или, например, цикл, когда тело не зависит от предыдущих итераций, можно выполнить в несколько параллельных линий.
Это не многозадачность/многопоточность! Здесь не требуется, например, изоляция контекстов потоков.
Должен быть механизм быстрого дешёвого порождения таких параллельных веток.

← →
Дмитрий Белькевич (2010-11-11 20:07) [188]

> Это не многозадачность/многопоточность

И как же данные "размажутся" между ядрами? Чудесным образом?

> И как же данные "размажутся" между ядрами? Чудесным образом?

Я не знаю как, ведь ядра доступа к общей памяти не имеют.
Наверное, придётся ждать разработки процессора, у которого ядра умеют читать из одной и той же области памяти.

← →
_oxffff (2010-11-11 20:25) [190]

> DiamondShark © (11.11.10 17:54) [184]
>
> > Mystic © (11.11.10 17:12) [181]
> > Шаблоны C++ это верх идеи о том, что все должно быть автоматизировано
>
> > компилятором. Соответственно, в результате имеем определенный
>
> > геморрой.
>
> Я выше писал, что как генератор идей C++ весьма очень даже.
>
> Сама идея шаблонов, параметризованного кода, обобщённого
> программирования -- хороша есть весьма.

The .NET generics are parameterized types with homogenous constrained
parameter lists, while C++ templates represent parameterized types with heterogeneous unconstrained parameter lists.

Тем не менее templates беспорно мощнее generics. Однако за такую мощь необходимо платить type checking в момент инстанцирования. В то время как тело generic возможно проверить в момент его определения.

> Реализация -- ни к чёрту.

А что есть уверенность что можно сделать по другому?

← →
_oxffff (2010-11-11 20:30) [191]

> Сейчас вот интел изобретает примочку в процессор, для анализа
> непосредственно потока команд и раскидывания по ядрам. Видимо,
> решил не ждать милостей от разработчиков компиляторов %(

Больно подозрительно выглядит!

Может имелось ввиду совместное использование исполнительных устройств между ядрами в зависимости от нагрузки.

У AMD в следующем году выйдет процессор Bulldozer c разделяемым FPU между двумя ядрами. FLEX FP

http://www.bit-tech.net/news/hardware/2010/10/28/amd-unveils-flex-fp/1
http://www.xbitlabs.com/news/cpu/display/20101026234515_AMD_Calls_New_FPU_Flex_FP_Defends_Dual_FMAC_Approach.html

← →
_oxffff (2010-11-11 20:40) [192]

> Сейчас вот интел изобретает примочку в процессор, для анализа
> непосредственно потока команд и раскидывания по ядрам. Видимо,
> решил не ждать милостей от разработчиков компиляторов %(
>
> Подчеркну, что я не многозадачность говорю, а именно про
> внутренний параллелизм. Что-то типа такого:
> a := (X + Y) * (U - V);
> Подвыражения "(X + Y)" и "(U - V)" можно вычислить на разных
> ядрах параллельно.

Это есть и сейчас и называется внеочередным исполнением команд. Зависимости отслеживаются еще со времен Intel Pentium PRO.

> Тем не менее templates беспорно мощнее generics. Однако
> за такую мощь необходимо платить type checking в момент
> инстанцирования. В то время как тело generic возможно проверить
> в момент его определения.

Сделать как в Ada: вместе с описанием типа необходимо описать все требования к нему? Например:

generic type Element is limited private; with function "="(E1, E2 : Element) return Boolean; with procedure Assign(E1, E2 : Element); package Stuff is . . .

← →
Дмитрий Белькевич (2010-11-11 20:46) [194]

> внеочередным исполнением команд

В пределах одного ядра, не?

← →
_oxffff (2010-11-11 21:00) [195]

> Mystic © (11.11.10 20:45) [193]

Если между параметрами типами можно определить ограничения например так:

ClassA<T,U> where T:U.
{
a:T;
b:U;
..
{b:=a; } безопасно поскольку T является подтипом U.
Тело можно проверить.
..
}
Это generics.

Теперь templates

ClassA< Func(U->T), Z, Func2(U,Z->E)>
{
a:Func<nteger>;
b:Func<Z>;
c:Func2<integer,Z>
d:Func2<integer,Func<Z>>

..
{b:=a;
c:=d;
} Проверить нельзя поскольку тело Func и Func2(функции из вида в вид)
неизвестно.
..
}

где вид-это тип, или функция из вида в вид.
Вводить отношения между функциями из вида в вида сложно(с ограничениями) если вообще возможно . Поскольку для
одних параметров они коварианты, для других контвариантны, для других инварианты.

Так что не нужно катить бочку на С++.
Я хоть не сторонник C++. Но тем не менее его уважаю. :)

← →
_oxffff (2010-11-11 21:08) [196]

> Дмитрий Белькевич (11.11.10 20:46) [194]
>
> > внеочередным исполнением команд
>
>
> В пределах одного ядра, не?

Мне видится, что они могут сделать общий пул исполнительных устройств на несколько ядер. В зависимости от нагрузки ядра они могут распределяться динамически. Сейчас у каждого ядра свой набор таких устройств.

> Похожее умел ещё Турбо-Паскаль 5.5. Он старался сгенерировать
> код, максимально использующий возможность параллельной работы
> CPU и FPU. Чем не прообраз многоядерного параллелизма?

Автор жжет. Пиши ясчё.

← →
Дмитрий Белькевич (2010-11-11 21:51) [198]

> Автор жжет. Пиши ясчё.

Ну я уже не стал комментировать :) Но таки да.

> Сейчас у каждого ядра свой набор таких устройств.

Ну как я себе представляю, то ядра на кристалле разделены топографически, или я не прав, и ядра могут юзать куски друг друга?

> В зависимости от нагрузки ядра они могут распределяться
> динамически.

itanium или Cell такое таки умеют.

> или я не прав, и ядра могут юзать куски друг друга?

Аппаратно не умеют. SMP от intel вообще отделены намертво. От AMD могут плевать друг в друга данными почти без потерь на синхронизацию.

Софтверно - я же давал ссылку на GrandCentral - она умеет куски кода нарезать и отправлять по процессорам. Но это только при их сборщике мусора.

← →
_oxffff (2010-11-11 22:07) [200]

> Дмитрий Белькевич (11.11.10 21:51) [198]
>

> > Сейчас у каждого ядра свой набор таких устройств.
>
>
> Ну как я себе представляю, то ядра на кристалле разделены
> топографически, или я не прав, и ядра могут юзать куски
> друг друга?

Разделение на физические ядра условно.
Прочитайте про архитектуру AMD Bulldozer.

это первая страница
http://www.realworldtech.com/page.cfm?ArticleID=RWT082610181333&p=1

Внизу оглавление

Высокий/низкий уровень, ручное/автоматическое управление Найти похожие ветки