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

← →
_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

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

← →
tesseract © (2010-11-11 22:10) [201]

> Прочитайте про архитектуру AMD Bulldozer.

Оно уже вышло? Если llvm победит, то разделение и на архитектуру процессоров можно будет считать условной :-)

← →
_oxffff (2010-11-11 22:18) [202]

> tesseract © (11.11.10 22:10) [201]

В 2011.

← →
Pavia © (2010-11-11 22:30) [203]

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

Смотря что понимать под ядрами. К примеру core 2 due это двух ядерный. Но имеют общий кэш третьего уровня. Через которое и происходит общение.

А вот Pentium D хоть и считается одноядерным имеет HT. Фактически это 2 ядра тесно связанных друг с другом и имеющие общие блоки такие как АЛУ, мэнеджер питания и др которые они делят между друг другом.

К примеру Pentium pro имеет два АЛУ. Которые может загружать параллельно.
А вот на видео карте нет ядер как таковых там АЛУ но их много. И производитель называет их ядрами. При этом АЛУ связанны в виде матрицы и данные из одного АЛУ в другое передаются по цепочки.

А вообще при производстве процессора ядра получают не столько физическим дублированием сколько программным при проектировании. И там уже разводят связи. Так что топографический они всё-таки связаны.
Хотя раньше были разделены.

← →
картман © (2010-11-11 22:40) [204]

>
> А вот Pentium D хоть и считается одноядерным имеет HT. Фактически
> это 2 ядра тесно связанных друг с другом и имеющие общие
> блоки такие как АЛУ, мэнеджер питания и др которые они делят
> между друг другом.

ага, два, конечно, а ты попробуй создай по потоку на ядро HT и посчитай, что получится

← →
Pavia © (2010-11-11 22:48) [205]

> ага, два, конечно, а ты попробуй создай по потоку на ядро
> HT и посчитай, что получится

А зачем считать? Это и так известно. И в книжках было описано еще до моего появления на свет.
1. Проблема вытеснения. Два потока будут просто мешать друг дружке.
2. Либо проблема балансировки нагрузки. Не до загруженности второго даже при наличии свободных блоков.

← →
картман © (2010-11-11 22:54) [206]

> Pavia © (11.11.10 22:48) [205]

я к тому, что ядро там одно, если судить по работе процессора

← →
Дмитрий Белькевич (2010-11-11 22:58) [207]

По поводу гипертридинга я вкурсе, больше инетересовали полноценные ядра.

Вообще, возможно были бы интересны некие "надпроцессные" команды. Т.е. такой расширенный набор надпроцессных команд, который бы помогал параллелить код. Думается, что тут со стороны железа можно было что-то сделать. Типа - вот отсюда начинается много-процессный кусок, считать его 2-4-8-ю ядрами, вот здесь - конец куска.

← →
Дмитрий Белькевич (2010-11-11 22:59) [208]

>"надпроцессные"

читать - надпроцессорные. или надядерные.

← →
Pavia © (2010-11-11 23:02) [209]

> Вообще, возможно были бы интересны некие "надпроцессные"
> команды. Т.е. такой расширенный набор надпроцессных команд,
> который бы помогал параллелить код. Думается, что тут со
> стороны железа можно было что-то сделать. Типа - вот отсюда
> начинается много-процессный кусок, считать его 2-4-8-ю ядрами,
> вот здесь - конец куска.

Уже существу причем как 10 лет. 10 лет по компьютерным меркам эпоха. Называется OpenMP. Но правда доступен для C++ и ряда других языков в которые Delphi не входит.

← →
_oxffff (2010-11-11 23:05) [210]

> Дмитрий Белькевич (11.11.10 22:58) [207]

Зачем? Есть VLIW.

Эльбрус. Itanium

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

Ну, OpenMP это, как я понял, софтверные надстройки над уже имеющимся железом. Больше интересны железячные надстройки.

← →
Дмитрий Белькевич (2010-11-11 23:10) [212]

> Эльбрус. Itanium

На x86 бы, остальное экзотично и неитересно.

← →
Дмитрий Белькевич (2010-11-11 23:12) [213]

Я понимаю, что, по хорошему, нужно глобально всю компьютерную архитектуру менять. Но, давайте будет реалистами, этого никто не сможет и не будет делать. По крайней мере, до появления 100% работоспособных эмуляторов винтела.

← →
Pavia © (2010-11-11 23:28) [214]

Все мультимедийные расширения такими являлись.
Pentium ввели парализация исполнения команд. Два ALU
Pentium II ввели MMX. Одна команда обрабатывает вектор данных. 8 байт или 4 Word или 2 int. Тут вопрос в том как считать это одно алу обрабатывает или 8, 4, 2 ? Интел считает что одно. А некоторые разработчики считают что это 2,4,8 ядер!

Дальше парализация шла также.
Pentium III SSE регистр стал 128битным те поддерживают в 2 раза больше данных.

Pentium 4. Просто подняли скорость. Но разрешили на одном такте выполнять несколько команд.

Зато AMD пошла известным путем больше регистр больше данных можно обрабатывать. И ввела 256битные регистры.

← →
DiamondShark © (2010-11-11 23:40) [215]

> Я понимаю, что, по хорошему, нужно глобально всю компьютерную
> архитектуру менять.

Зачем менять?
Разработки процессоров, языков, компиляторов и ОС должны быть согласованы.
Вот это и будет реализм.

← →
Игорь Шевченко © (2010-11-12 00:09) [216]

Pavia © (11.11.10 23:28) [214]

Изучай http://www.intel.com/Assets/PDF/manual/253665.pdf

← →
Pavia © (2010-11-12 00:22) [217]

> Игорь Шевченко © (12.11.10 00:09) [216]
> Pavia © (11.11.10 23:28) [214] Изучай http://www.intel.
> com/Assets/PDF/manual/253665.pdf

От предыдущего издания сильно отличается?

← →
Игорь Шевченко © (2010-11-12 00:30) [218]

Pavia © (12.11.10 00:22) [217]

История изменений архитектуры - вряд ли :)

← →
Mystic © (2010-11-12 10:20) [219]

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

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

← →
oxffff © (2010-11-12 10:47) [220]

> Mystic © (12.11.10 10:20) [219]
>
> > Вводить отношения между функциями из вида в вида сложно(с
>
> > ограничениями) если вообще возможно . Поскольку для
> > одних параметров они коварианты, для других контвариантны,
>
> > для других инварианты.
>
>
> Ну вот в Ada нужно все это описать. Мне этот подход нравится
> больше, потому что накрывает самый часто используемый случай,
> оставляя в стороне всякие запутанные вещи.

Например

То есть видовая функция T->U из типа в типа(читай параметризованный тип).

Есть две реализации этого вида. Например

ParametrizedClassA<T>=inteface
A:T;
function (a:T):integer;
end;

ParametrizedClassB<T>=inteface
A:T;
function (a:T):integer;
end;

ParametrizedClassС<T>=record
A:T;
function (a:T):integer;
end;

Есть еще параметризованный тип:

TemplateMain<A,B, C(T->U),D(T->U))=class
a:C<A>;
b:D;

{
a:=b <-Как проверить, что это безопасно?
}
end;

Для
TemplateMain<Tform,TControl,ParametrizedClassA,ParametrizedClassB> это безопасно.

А для
TemplateMain<TControl,Tform,ParametrizedClassA,ParametrizedClassB> это ошибка.

И для
TemplateMain<TControl,Tform,ParametrizedClassA,ParametrizedClassC> это ошибка.

Как задать такое в Ada(написать отношения между функциями из типа в тип например)?
Мне представляется, что никак.

← →
oxffff © (2010-11-12 10:49) [221]

Есть еще параметризованный тип:

TemplateMain<A,B, C(T->U),D(T->U))=class
a:C < A >;
b:D < B >;

{
a:=b <-Как проверить, что это безопасно?
}
end;

Для
TemplateMain<Tform,TControl,ParametrizedClassA,ParametrizedClassB> это безопасно.

А для
TemplateMain<TControl,Tform,ParametrizedClassA,ParametrizedClassB> это ошибка.

И для
TemplateMain<TControl,Tform,ParametrizedClassA,ParametrizedClassC> это ошибка.

Как задать такое в Ada(написать отношения между функциями из типа в тип например)?
Мне представляется, что никак.

← →
Вариант (2010-11-12 11:52) [222]

> oxffff © (12.11.10 10:49) [221]

Когда в ада создается (описывается) какой-либо новый тип - программист обязан написать все необходимые преобразования нового типа в другие. Если преобразования не существует - то это не пройдет на этапе компилятора. Если тип является наследуемым(подтипом), то он может и унаследовать существующие правила преобразования. А потому в ADA95 (2005 не знаю) преобразование типа в тип безопасно - компилятор не пропустит, если нет правила преобразования

← →
Mystic © (2010-11-12 12:09) [223]

Что мешает для этой операции присваивания определить специальную функцию, которую нужно будет описывать руками?

Вообще, пример достаточно мутный, если честно.

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

a = b;

По сути это

A& operator = (A& a, const B& b) { /* ... */ }

Что мешает дополнить шаблон явным указанием такой функции?

← →
oxffff © (2010-11-12 12:17) [225]

> Вариант (12.11.10 11:52) [222]

Между конкретным типом(integer,Tlist<integer>) и просто функцией из типа в тип(TList<>) есть разница.

Generic Ada не позволяет принимать качестве параметра другой generics, только конкретный тип, либо экземпляр другого generic"а, но не сам generic.
Так что Ada generics не являются аналогом С++ templates.

← →
Mystic © (2010-11-12 12:25) [226]

> Generic Ada не позволяет принимать качестве параметра другой
> generics, только конкретный тип, либо экземпляр другого
> generic"а, но не сам generic.
> Так что Ada generics не являются аналогом С++ templates.

Что мешает его явно описать и передать?

generic type Element is private; package XXX is type ElementArray is array(1..200) of Element; private -- implementation end Stacks;

и потом

package YYY is new XXX(Element => Boolean); package ZZZ is new XXX(Element => YYY.ElementArray);

← →
oxffff © (2010-11-12 12:26) [227]

> Mystic © (12.11.10 12:12) [224]
> a = b;
>
> По сути это
>
> A& operator = (A& a, const B& b) { /* ... */ }
>
> Что мешает дополнить шаблон явным указанием такой функции?
>

В С++ шаблоны можно передевать в качестве параметра другие шаблоны. А поскольку шаблон является параметром шаблона проверить его в использующем шаблоне нельзя пока не будет предоставлено его тело(инстанцирование шаблона)

Еще раз

Два шаблона

ParametrizedType1<T>=inteface
...
end;

ParametrizedType2<T>=inteface
....
end;

Шаблон принимающий другие шаблоны.

MainClass<typeparam, templateparam1,templateparam2>=class
{
a:templateparam1<typeparam>; <- это некий тип построен по шаблону параметру templateparam1

b:templateparam2<integer>; <- это некий другой тип построен по шаблону параметру templateparam2
}

a:=b; <- нельзя проверить поскольку шаблоны параметры неизвестны(здесь нет их тела!!!)
end

Однако теперь проверить можно

MainClass<integer,ParametrizedType1,ParametrizedType2>

поскольку теперь известно тело типа.

a:ParametrizedType1<typeparam>
b:ParametrizedType1<integer>

Так понятней? :)

← →
oxffff © (2010-11-12 12:27) [228]

> a:ParametrizedType1<typeparam>
> b:ParametrizedType1<integer>

a:ParametrizedType1<typeparam>
b:ParametrizedType2<integer>

← →
Вариант (2010-11-12 12:29) [229]

> oxffff © (12.11.10 12:17) [225]

Абстрактный тип - так это называется в ADA95. Аналогом чего-либо в с++ не является. Не может быть использован явно, только для порождения других типов. (с этим и не спорят) -
Преобразования порожденных типов в другие типы является безопасным см[222] - это ответ на вопрос

> oxffff © (12.11.10 10:47) [220]

> {
> a:=b <-Как проверить, что это безопасно?
> }

> Mystic © (12.11.10 12:25) [226]
>
> > Generic Ada не позволяет принимать качестве параметра
> другой
> > generics, только конкретный тип, либо экземпляр другого
>
> > generic"а, но не сам generic.
> > Так что Ada generics не являются аналогом С++ templates.
>
>
>
> Что мешает его явно описать и передать?
>
>
> generic
> type Element is private;
>
> package XXX is
> type ElementArray is array(1..200) of Element;
> private
> -- implementation
> end Stacks;
>
> и потом
>
>
> package YYY is new XXX(Element => Boolean);
> package ZZZ is new XXX(Element => YYY.ElementArray);

Это не аналогичный финт. Поскольку ZZZ интанцируется уже готовым типом,

но вот так(я не знаю синтасис. Учусь по твоему примеру)

generic
type Element is private;

package XXX is

is new Element(integer);
....

generic
type Element is private;

package YYY is
....

package ZZZ is new XXX(YYY);

но вот так в Ada нельзя. А в С++ можно.

> Вариант (12.11.10 12:29) [229]
>
> > oxffff © (12.11.10 12:17) [225]
>
> Абстрактный тип - так это называется в ADA95. Аналогом
> чего-либо в с++ не является. Не может быть использован явно,
> только для порождения других типов. (с этим и не спорят)
> -
> Преобразования порожденных типов в другие типы является
> безопасным см[222] - это ответ на вопрос
>
> > oxffff © (12.11.10 10:47) [220]
>
>
>
> > {
> > a:=b <-Как проверить, что это безопасно?
> > }

Твой ответ неверный. Перечитай еще раз.

>
> В С++ шаблоны можно передевать в качестве параметра другие
> шаблоны. А поскольку шаблон является параметром шаблона
> проверить его в использующем шаблоне нельзя пока не будет
> предоставлено его тело(инстанцирование шаблона)

Проведи инстанцирование ручками и передай полученный тип в качестве параметра... В C++ typedef это не определение типа и не приводит к инстанцированию. Но в Ada это же не так.

> package ZZZ is new XXX(YYY);
> но вот так в Ada нельзя. А в С++ можно.

Я и говорю, что это легко можно обойти, напрямую ручками перечислив все фичи YYY, которые используются в XXX.

> Mystic © (12.11.10 12:34) [232]
>
> >
> > В С++ шаблоны можно передевать в качестве параметра другие
>
> > шаблоны. А поскольку шаблон является параметром шаблона
>
> > проверить его в использующем шаблоне нельзя пока не будет
>
> > предоставлено его тело(инстанцирование шаблона)
>
>
> Проведи инстанцирование ручками и передай полученный тип
> в качестве параметра... В C++ typedef это не определение
> типа и не приводит к инстанцированию. Но в Ada это же не
> так.

Это ограничение позволяет проверять типы в теле generic.

Но не позволяет достраивать(изменять) тело шаблона в момент его инстанцирования. Это все приводит к тому что для generics выводят некий общий интерфейс которому все соответствует и работают с ним. А в С++ получается duck typying(привет Alkid"у).

← →
Вариант (2010-11-12 12:43) [235]

> oxffff © (12.11.10 12:33) [231]

Ада, язык, типы - сильно отличаются от дельфи или с#. Там упор сделан на безопасности программировании, вылавливании блох на этапе компиляции. А потому правильней сказать что вопрос в [220] по отношению к ADA неверный - преобразование типов всегда будет безопасным, допустимым - ибо его прописали. Если нет преобразования, то это не пройдет на этапе компиляции. И проверять тип будет компилятор на этапе компиляции, а не на этапе выполнения программы

> Но не позволяет достраивать(изменять) тело шаблона в момент
> его инстанцирования. Это все приводит к тому что для generics
> выводят некий общий интерфейс которому все соответствует
> и работают с ним. А в С++ получается duck typying(привет
> Alkid"у).

Ну все это можно обойти :) Например:

template<typename X> class Y { X x; public: Y(): x() { x.init(); } }

Тут мы не можем узнать, имеет ли тип x метод init с нужной сигнатурой, можем проверить только на этапе инстанцирования (duck typing). Но что мешает поступить так?

generic type X is private; with procedure Init_X(Arg_X: X); package ...

Т. е. нам надо будет указывать руками дополнительно функцию, которую мы хотим использовать в качестве функции init.

> Mystic © (12.11.10 12:38) [233]
>
> > package ZZZ is new XXX(YYY);
> > но вот так в Ada нельзя. А в С++ можно.
>
>
> Я и говорю, что это легко можно обойти, напрямую ручками
> перечислив все фичи YYY, которые используются в XXX.

Это не совсем так. То есть для того чтобы это обойти придется городить общий для всех таких разновидностей YYA,YYB,YYC.. некий общий интерфейс YYY, через который по факту будет происходить вызов.
Поэтому .NET C# generics на параметрами типами можно производить только
операции присваивания, все остальное (+,-,*,/ ,сравнения) через общий интерфейс. Например такой IComparer<T,Z>=function (left:T;right:Z):boolean;

Но вот тут начинаются настоящие грабли.

Дано:

generic<T,Z,comparer<T,Z>) Z:T;
{
a:T;
b:Z;

a:=b;
adder(a,b);
}

Экземпляр
<Tcontrol,Tform,Unicomparer>

перегрузка неразрешима и придется делать так

Unicomparer(a:Tobject,b:Form)
{
if a is TWinControl and b is Tform1 then
.....
begin
end
else
if a is TGraphicControland b is Tform1 then
...
........

}

А это проблема!!!!!

> oxffff © (12.11.10 12:52) [237]

generic type X is private; type Y is private; package Unicomparer procedure Something(Arg_X: X; Arg_Y: Y); -- .......

Далее

generic type X is private; type Y is private; with procedure Something(Arg_X: X; Arg_Y: Y); package DifficultCase -- ...

Ну и в коде

package ComparerForm is new Unicomparer(X => TControl, Y => TForm); package ExtraDifficultCase is new DifficultCase(X => TControl, Y => TForm; Something = ComparerForm.Something);

← →
Какой кыашмар (2010-11-12 14:17) [239]

Дмитрий Белькевич (10.11.10 12:51) [66]

> Вообще, я, по одной из специальностей, инженер-электронщик.
> Я как бы в курсе :) Что для чайников и утюгов и прочих
> свистоперделок выпускается множество всякого.

Я Вам по секрету скажу, как инжинер инженеру. Архитектуры x86 уже нету, давно. С выхода P4, ага. Система команд x86 эмулируется. Вот такой вот интерпретатор встроен в процессор, который преобразует x86-фигню в удобоваримый набор инструкций. На IA-64 уже свой набор инструкций, доступный программисту и компилятору. И присобаченный эмулятор для разбора x86-фигни. Тока работает он в режиме эмуляции x86 куда медленней. Не за горами момент когда эту обузу - поддержку x86-совместимости - отправят на свалку истории.

> Какой кыашмар (12.11.2010 14:17:59) [239]

В пользу простых, симметричных инструкций, без команд умножения/деления.

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