Здравствуйте, cl-user, Вы писали:

CU>>>Что значит "хорошо перемешивать"?
AVM>>Брать большие по размеру доли и смешивать их, чтобы можно было пренебречь погрешностью отмеривания долей.
CU>Тогда будет как с винами: такой-то год, такой-то берег такой-то реки... Алхимия в средневековье, а не наука и промышленность века нашего.
Лет 500 назад алхимия была ого-го наукой. Лет через 500 про нас тоже скажут — алхимия

CU>>>>>А на клеточном уровне всё равно идёт обмен сигналами.
AVM>>>>Вопрос "какими сигналами?" Ответа естественно не жду, т.к. это пока тайна за семью печатями.
CU>>>Вам перечислить _все_ сигналы? Так это и о написанных программах уже не скажешь. А перечислить характер "сигналов" — запросто. Хотя да — алгоритмы реакции пока не ясны.
AVM>>Не надо перечислять. Я не уверен что известны даже все характеры сигналов.
CU>Физика? (электро-магнитные) Химия (органическая и неорганическая)? Что ещё?
Я не знаю. Просто думаю, что есть что-то еще. Нет не высший разум. Просто есть вещи, которые современной наукой до конца не изучены. Уверен, что появятся новые науки и что современная физика будет значительно расширена и обновлена.

CU>>>Хм, скорость штамповки DVD по матрице? Не прожиг в DVD-ROM, а именно штамповка.
AVM>>Штамповку и получим, а толку от нее?

CU>_ТОЧНАЯ_ копия.

AVM>>Если серьезно, то на базе этого механизма (хранение генома в клетке) в перспективе можно строить очень хорошие хранилища информации: отношение емкость/размер — огромное, энергопотребление — низкое, защита информации от потерь — великолепная. Есть правда и куча минусов, основной — мы до сих пор не знаем как оно работает

CU>Скорее всего произвольную последовательность хранить не получится...
Не знаю. Знаю только что сейчас там хранение организовано намного эффективнее чем хранение 0 и 1 на магнитном диске.

E>Т.е. ACE_Reactor работает в качестве мультиплексора (или демультиплексора -- путаюсь в этих терминах) событий.
демультиплексора
из одной точки программы у нас могут вылазить разные события, и соотв. разные пути исполнения. Если нарисовать это на блок-схеме — получится что-то подобное демультиплексору из схемотехники

E>В простейшем случае ACE_Reactor является оберткой над while{} c select-ом внутри.
Или WaitForMultiplyObjects, если iZEN Windows ближе чем Linux или BSD-шные сокеты

А вообще, паттерн так и называется — Reactor, гуглом можно найти массу внятных описАний.

S>Как именно инкредибилд использует дисковый кэш, мне не известно. Но размер самого большого объектника у меня в проекте меньше 32 Мб, pch — меньше 20 Mb, инкредибилдовские куски pdb тоже не особо здоровые. Все вполне влазит в ОЗУ.
Для случая билда одного файла в одном проекте. Перемножь это на кол-во машин, которое использует IncrediBuild. Ну и опять же — размер ОЗУ != размеру файлового кэша.

S>Как именно инкредибилд использует дисковый кэш, мне не известно.
Если очень интересно узнать читает ли он ВСЕ файлы или только те которые билдятся на этой машине — можно довольно просто посмотреть ProcessMonitor-ом.

Здравствуйте, GlebZ, Вы писали:

GZ>Здравствуйте, AVM, Вы писали:

AVM>>Вот блин и приплыли. В соответствии с Тезисом Чёрча—Тьюринга все можно посчитать с помошью машины Тьюринга.
GZ>Не понял??? В соответсвии с этим тезисом любая вычислимая функция может быть частично вычислена машиной Тьюринга. То есть с достаточном приближением. Вычислимость функции предполагает ее измеримость. То есть, ее можно вычислить данной машиной до определенной степени точности. Если у тебя величина бесконечность, то почему бы бесконечность не принять за некоторое значение обладающее соответвующими свойствами (есть же такое значение как null или NaN).
В соответствии с тезисом "интуитивно вычислимая функция является частично вычислимой. Частично вычислимая может быть посчитана на машине Тьюринга". (Доказать или опровергнуть это не возможно, т.к. не совсем понятно что есть интуитивно вычислимая функция).
Я не уверен, что пространство и время можно описать интуитивно вычислимой функцией. Следовательно я не уверен, что можно "обсчитать" пространство и время на машине Тьюринга.
Это можно развивать дальше, но IMHO продолжать смысла нет.

"Left2" <13414@users.rsdn.ru> wrote in message news:2691870@news.rsdn.ru...
>S>Как именно инкредибилд использует дисковый кэш, мне не известно. Но размер самого большого объектника у меня в проекте меньше 32 Мб, pch — меньше 20 Mb, инкредибилдовские куски pdb тоже не особо здоровые. Все вполне влазит в ОЗУ.
> Для случая билда одного файла в одном проекте. Перемножь это на кол-во машин, которое использует IncrediBuild.

10 машин — все равно временное барахло в озу влазит.

> Ну и опять же — размер ОЗУ != размеру файлового кэша.

Ну и каким образом все это может сделать утверждение "Что касается С++, то там те же проблемы. Дополнительный проц не сильно увеличит скорость компиляции" справедливым? Пока у нас отнюдь не 80 процессоров, а 1-2-4, и дополнительный проц весьма сильно влияет на скорость компилляции. А когда ядер будет 80, так и памяти наверняка прибавится, и многоканальной ее скорее всего сделают (если, конечно, маркетинг в очередной раз не восторжествует над разумом)).

"Left2" <13414@users.rsdn.ru> wrote in message news:2691879@news.rsdn.ru...
>S>Как именно инкредибилд использует дисковый кэш, мне не известно.
> Если очень интересно узнать читает ли он ВСЕ файлы или только те которые билдятся на этой машине — можно довольно просто посмотреть ProcessMonitor-ом.

Казнить нельзя помиловать. Ничего не понял. Кстати, файлы в кэше у него лежат мелкие, больше мегабайта только индекс.

Здравствуйте, AndrewVK, Вы писали:

ZEN>>Но всё это костыли. Если всё рабочее окружение отправить в своп, а при загрузке компьютера оотуда всё доставать в оперативку...
AVK>В Windows это называется hibernate. К сожалению, при современных объемах оперативки и скоростях винтов это не очень быстро.
На 3 гб и обычном SATA2 венике hibernate занимает секунд 5
ВСЯ память будет записана только если она ВСЯ занята.
Обычно пишется только реально занятые участки минус кэш

S>10 машин — все равно временное барахло в озу влазит.
Что говорит о том, что Incredibuild не читает его постоянно с твоей машины, а хранит на чужих билд-машинах.

Здравствуйте, AVM, Вы писали:

AVM>В соответствии с тезисом "интуитивно вычислимая функция является частично вычислимой. Частично вычислимая может быть посчитана на машине Тьюринга". (Доказать или опровергнуть это не возможно, т.к. не совсем понятно что есть интуитивно вычислимая функция).
Ты их недооцениваешь. То что и Тьюринг, и лямбда Черча вычислимо полные машины — уже доказано (по моему ими же). Существует также такой раздел математики как "теория вычислимости", где описывается вычислимость той или иной модели.


AVM>Я не уверен, что пространство и время можно описать интуитивно вычислимой функцией. Следовательно я не уверен, что можно "обсчитать" пространство и время на машине Тьюринга.
А вот вопрос "обсчитать пространство и время" — уже непонятно.

AVM>Это можно развивать дальше, но IMHO продолжать смысла нет.
Согласен.

>S>10 машин — все равно временное барахло в озу влазит.
> Что говорит о том, что Incredibuild не читает его постоянно с твоей машины, а хранит на чужих билд-машинах.

Ясное дело, что Incredibuild не читает объектники постоянно с моей машины, а сам их генерирует Я немного о другом говорю — работа с диском при компилляции у меня узким местом не является, скорость упирается в процессор. Собственно, даже по загрузке процессора это видно. А об винт оно тормозит при линковке и склеивании pdb.

Здравствуйте, VladD2, Вы писали:

VD>Кроме того есть проблема сложности. Одна и та же задача может быть решена совершенно с разными трудозатратами если выбирать более прямые методы решения. Ну, скажем у первых писюков была сегментная организация памяти и памяти явно было очень мало. Это вынуждало тратить тонну времени на то чтобы изобретать способы того как решить задачу в данных условиях. Сейчас у меня на машине 2Гб оперативки и я для многих задач могу выбрать весьма простые решения (скажем скачать 100 мегабайтный файл в память). Ранее я этого не мог. Далее, когда будет 1Тб пмяти я смогу, скажем использовать позиционную сортировку для int32. Сегодня это выглядит бредом. (в прочем может так будет и завтра ).
Если ты поставишь 1Тб и 80 ядерный процессор к себе на компьютер, то использовать позиционную сортировку ты все равно не сможешь. Сейчас мне пришлось заняться тиковыжимательством, и я пришел к выводу, что в нынешней архитектуре x86 нужно что-то менять. Проблема оказалась не в самом процессоре как таковом, он все успевает. Проблема оказалась в random доступе к памяти. Кэш проца в этом случае не спасает. Приходится сильно пере... алгоритмы чтобы запись была последовательна. Была еще проблема доступа к близким участкам памяти с нескольких процессоров. Но это достаточно легко решилось, хотя тоже через одно место.

ЗЫ. Что касается Desktop, то для большинства бизнес-приложений, ресурсы процессора избыточен. Меня пока в этом не переубедили.

Здравствуйте, Sergey, Вы писали:

S>Ну и каким образом все это может сделать утверждение "Что касается С++, то там те же проблемы. Дополнительный проц не сильно увеличит скорость компиляции" справедливым? Пока у нас отнюдь не 80 процессоров, а 1-2-4, и дополнительный проц весьма сильно влияет на скорость компилляции. А когда ядер будет 80, так и памяти наверняка прибавится, и многоканальной ее скорее всего сделают (если, конечно, маркетинг в очередной раз не восторжествует над разумом)).
А ты внимательно прочитал мое сообщение? У тебя 10 машин. Значит 10 шин памяти между процессором и OЗУ. Пока противоречия с моим утверждением — не вижу.

VD> Далее, когда будет 1Тб пмяти я смогу, скажем использовать позиционную сортировку для int32. Сегодня это выглядит бредом. (в прочем может так будет и завтра ).
Почему бредом, кстати? На 64-битных системах (а современные десктопные системы 64-битную адресацию тянут аппаратно) вроде бы всё должно быть нормально, даже 4 гб оперативной памяти иметь не надо — достаточно 4 гб виртуальной, и то — в самом худшем случае

Здравствуйте, alpha21264, Вы писали:

iZEN>>А вот команда make -j2 действительно увеличила скорость компиляции 2,5 раза.

A>Всяко бывает. Они ведь еще и кеш могут друг у друга отбирать. А... после j пробел стоял?

Пробел не нужен.

Здравствуйте, GlebZ, Вы писали:

GZ>Здравствуйте, Sergey, Вы писали:

S>>Ну и каким образом все это может сделать утверждение "Что касается С++, то там те же проблемы. Дополнительный проц не сильно увеличит скорость компиляции" справедливым? Пока у нас отнюдь не 80 процессоров, а 1-2-4, и дополнительный проц весьма сильно влияет на скорость компилляции. А когда ядер будет 80, так и памяти наверняка прибавится, и многоканальной ее скорее всего сделают (если, конечно, маркетинг в очередной раз не восторжествует над разумом)).
GZ>А ты внимательно прочитал мое сообщение? У тебя 10 машин. Значит 10 шин памяти между процессором и OЗУ. Пока противоречия с моим утверждением — не вижу.

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

Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Константин Л., Вы писали:

[]

Ты хочешь сказать, что я могу не использовать Interlocked для изменения 32 битных чисел из разных трэдов и при этом _каждый_ трэд будет видеть их без задержек?

Здравствуйте, remark, Вы писали:

R>http://developer.intel.com/products/processor/manuals/318147.pdf

И где там про неявные барьеры памяти?

Здравствуйте, Кодт, Вы писали:

В этом смысле Cell интересно сделан.

Здравствуйте, Lazy Cjow Rhrr, Вы писали:

LCR>В случае for-each-ей (фурычей ) — согласен, легко "векторизовать". А когда обработка элемента требует знания о случайном уже обработанном элементе? Как это векторизовать? Или там деревья какие-нибудь приплести, графы там...

J (не K) есть function-level язык (см. известную лекцию Бэкуса) — язык, выражения которого поддаются алгебраической трансформации куда лучше "классических" языков (что включает в себя, например, доказательство _эквивалентности_ выражений/конструкций). Это, как мне видится облегчает _выделение_ тех участков программы которые теоретически могут быть исполнены параллельно. Т.е. чуда же здесь нет — если для следующего шага требуются знания результата предыдущего — то это на любой архитектуре будет, в конечном итоге, исполнено последовательно. Но если что-то теоретически может быть вычислено параллельно, то, как мне видится, транслятор векторных языков имеет куда более высокие шансы _выявить_ эти самые параллельные моменты. Только и всего.

LCR>МТ = Машина Тьюринга. Вот про лямбда-исчисление доказано, что да, оно эквивалентно МТ, поэтому в лямбда-исчислении нет никаких форов, а вот в J — увы. То есть, имхо, причина — не параллельность, а полнота.

Насколько я понимаю, на сегодняшний день считается, что а) любая вычислительная система может быть промоделированная МТ, б) как следствие, любая существующая вычислительная система не мощнее (а значит _слабее_) МТ (хотя и возможно и даже скорее всего, превосходит МТ по оптимальности на некоторых задачах) и значит для теоретических нужд может быть сведена к МТ (в частности релевантная данной теме "многоленточная МТ" тоже сводится к простейшей МТ), в) лямбда-калькулис эквивалентен МТ и может быть использован как замена для теоретических выкладок.
Форов в лямбде нет, но есть рекурсия через Y-combinator, так что фор имплементируется элементарно... Так что я не вполне понимаю ваши опасения по поводу полноты: в любом случае любая из существующих реальных вычислительных систем-языков слабее МТ в силу "небесконечности" реальной ленты, но каждая из систем слабее с разной степенью удобства для программиста и возможного параллельного транслятора