WolfHound wrote: > Вобщем С++ хороший язык... когдато был... > А сейчас рулят ковровые клинья и танковые бомбандировки тфу ты > управляемые среды, а дальше будут рулить упровляемые ОС типа Singularity > для которых на С++ вобще писать будет довольно проблематично.
Да вы, батенька, оптимист.
Будут рулить вещи типа cell-архитектур для которых C# не подходит
абсолютно и полностью. С++ тоже плохо подходит, правда.
Здравствуйте, Cyberax, Вы писали:
C>Будут рулить вещи типа cell-архитектур для которых C# не подходит абсолютно и полностью. С++ тоже плохо подходит, правда.
О cell архитектурах на дешёвых линуксах я первый раз слышал ещё в 2001 году. Сразу отнёсся к этой идее скептически, т.к. ещё в 1991 приходилось возиться с транспьютерами. Похоже что для таких архитектур не только C# и C++ не подходит.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Cyberax, Вы писали:
C>Да вы, батенька, оптимист.
Бывает.
C>Будут рулить вещи типа cell-архитектур для которых C# не подходит абсолютно и полностью. С++ тоже плохо подходит, правда.
И чтоже такого в это архитектуре? Я просто не в курсе, а копатся в инете лень.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>И чтоже такого в это архитектуре? Я просто не в курсе, а копатся в инете лень.
Ничего особенного. Наращивание мощности путём добавления дешёвых элементов. Например, замена одного современного Windows сервера двумяста PII с линуксом. Проблема только в том, что 50% полученных ресурсов уходит на управление взаимодействием этого стада.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Ничего особенного. Наращивание мощности путём добавления дешёвых элементов. Например, замена одного современного Windows сервера двумяста PII с линуксом. Проблема только в том, что 50% полученных ресурсов уходит на управление взаимодействием этого стада.
Кластер чтоли?
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
IT wrote: > C>Будут рулить вещи типа cell-архитектур для которых C# не подходит > абсолютно и полностью. С++ тоже плохо подходит, правда. > О cell архитектурах на дешёвых линуксах я первый раз слышал ещё в 2001 > году. Сразу отнёсся к этой идее скептически, т.к. ещё в 1991 приходилось > возиться с транспьютерами. Похоже что для таких архитектур не только C# > и C++ не подходит.
Ну PS3 и Xbox2 переводит Cell'ы в ранг реальных продуктов. Учитывая
сегодняшнюю гонку числа ядер процессоров, явно всплывут идеи ncNUMA или
подобных извращений.
C# для них не подходит совершенно (так как появляется различие между
разными типами памяти, менее жесткая модель памяти и т.п). С++ подходит,
но плохо (руками за всем следить надо). Так что ждем появления новых языков.
WolfHound wrote: > C>Будут рулить вещи типа cell-архитектур для которых C# не подходит > абсолютно и полностью. С++ тоже плохо подходит, правда. > И чтоже такого в это архитектуре? Я просто не в курсе, а копатся в инете > лень.
Один центральный процессор и семь SPU (Sinergetic Processing Elements) —
простых процессоров без out-of-order execution, имеющих свою собственную
память (около 256Кб) и специальные наборы команд. То есть программа на
основном процессоре может взять какую-нибудь задачу и отправить ее на SPU.
Фишка в том, что SPU имеют доступ к основной памяти только через
достаточно медленный DMA.
IT wrote: > Ничего особенного. Наращивание мощности путём добавления дешёвых > элементов. Например, замена одного современного Windows сервера двумяста > PII с линуксом.
Нет! SPU в Cell предназначены для разгрузки основного процессора от
утилитных задач и не могут быть использованы в качестве основного
процессора.
При этом затраты на управление по сравнению с SMP — минимальны, так как
SPU не имеет прямого доступа в основную память.
Здравствуйте, Cyberax, Вы писали:
C>Один центральный процессор и семь SPU (Sinergetic Processing Elements) — простых процессоров без out-of-order execution, имеющих свою собственную память (около 256Кб) и специальные наборы команд. То есть программа на основном процессоре может взять какую-нибудь задачу и отправить ее на SPU.
Нашол какуюто статью но там както все мутно написано.
Я так понял что программа должна подготовить данные и код для SPU, а он очень быстро этот код с этими данными будет выполнять?
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Cyberax, Вы писали:
C>Будут рулить вещи типа cell-архитектур для которых C# не подходит C>абсолютно и полностью. С++ тоже плохо подходит, правда.
подозреваю, что как раз там будут рулить ФЯ
по крайней мере, функции без сторонних эффектов и лямбда-функции вполне этому способствуют
WolfHound wrote: > Нашол какуюто статью но там както все мутно написано. > Я так понял что программа должна подготовить данные и код для SPU, а он > очень быстро этот код с этими данными будет выполнять?
Примерно так, хотя выполнять он может и совсем не быстро.
Дарней wrote: > C>Будут рулить вещи типа cell-архитектур для которых C# не подходит > C>абсолютно и полностью. С++ тоже плохо подходит, правда. > подозреваю, что как раз там будут рулить ФЯ > по крайней мере, функции без сторонних эффектов и лямбда-функции вполне > этому способствуют
А еще функции должны работать только с ограниченым по размеру
окружением. И без всякого GC — он в 256Кб не поместится.
Здравствуйте, Cyberax, Вы писали:
C>А еще функции должны работать только с ограниченым по размеру окружением. И без всякого GC — он в 256Кб не поместится.
Функциональные вычисления очень хорошо поддаются автоматическому разбиению на части если это вобще возможно для выбранного алгоритма.
C>Так что С++ все же в более выгодном положении.
Не думаю.
Болие того я думаю что управляемая ОС сделаная на основе виртуальной машины которая поддерживает кроме императива еще и функциональные возможности будет лучше чем если там не будет этих возможностей.
Вобщем управляемые среды и здесь таки должны рулить.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
WolfHound wrote: > C>А еще функции должны работать только с ограниченым по размеру > окружением. И без всякого GC — он в 256Кб не поместится. > Функциональные вычисления очень хорошо поддаются автоматическому > разбиению на части если это вобще возможно для выбранного алгоритма.
Тем не менее, функциональные вычисления генерируют кучу мусора. А это
неприемлимо.
> C>Так что С++ все же в более выгодном положении. > Не думаю. > Болие того я думаю что управляемая ОС сделаная на основе виртуальной > машины которая поддерживает кроме императива еще и функциональные > возможности будет лучше чем если там не будет этих возможностей.
Управляемых ОС быть не должно. Нефиг в софте переделывать то, что
прекрасно делается в железе (тем более, что тенденция сейчас совсем
обратная).
> Вобщем управляемые среды и здесь таки должны рулить.
А смысл? Управляемость дает два преимущества:
1. Портируемость (не зависим от кодов процессора).
2. Возможную проверку корректности.
3. Динамическое исследование и модификация программы.
Первое преимущество для SPU не так важно, второе — на любителя
(аппаратная поддержка же есть). В теории, третее преимущество позволит
управляемой среде разбивать программу на куски и скармливать их в SPU.
Но текущая модель памяти CLR (однородной и бесконечной) этому как-то не
способствует.
Здравствуйте, Cyberax, Вы писали:
C>А еще функции должны работать только с ограниченым по размеру C>окружением. И без всякого GC — он в 256Кб не поместится.
Andrei N.Sobchuck wrote: > C>А еще функции должны работать только с ограниченым по размеру > C>окружением. И без всякого GC — он в 256Кб не поместится. > В 64 поместился <http://www.esmertec.com/solutions/M2M/OSVM/specs.shtml>, а в 256 никак?
Ага. Учитывая, что в этих процессорах выполняется не интерпретируемый
код, а быстрый скомпилированый.
Ничего кроме простенького mark&sweep в такие рамки положить не
получится, а от него мало толку будет.
Здравствуйте, Cyberax, Вы писали:
C>Тем не менее, функциональные вычисления генерируют кучу мусора. А это неприемлимо.
Это очень сильно зависит от алгоритма и от оптамизатора.
C>Управляемых ОС быть не должно.
Не согласен. C>Нефиг в софте переделывать то, что прекрасно делается в железе В том то и дело что плохо оно делается... в железе можно эффективно добится изоляции только довольно крупных кусков памяти иначе будет тАкой оверхед что мама не горюй.
А вот в управляемых средах можно изолировать хоть каждый байт и при наличии нормального оптимизатора можно выкинуть подавляющие большинство проверок просто статическим анализом.
Причем эта изоляция совсем не лишняя... ибо убирает очень большое колличество уязвимостей... да хотябы тоже переполнение буфера.
А самое смешное что программная изоляция получается эффективней аппаратной... C>(тем более, что тенденция сейчас совсем обратная).
Ага... Жаба и .НЕТ захватывают рынок... Делаются Жаба процессоры... Новый софт начинают писать на С++ все реже и реже...
C>Первое преимущество для SPU не так важно,
Кроме SPU есть еще куча других архитектур... на них софт тоже должен работать... C>второе — на любителя (аппаратная поддержка же есть).
То-то программы постоянно взламывают через переполнение буфера... Да и просто падение программы на ровном месте ничего хорошего не дает. Вот только не говори что это лечится прямыми руками... у кого эти прямые руки есть? Правильно у очень небольшой части программистов. Короче это не на любителя это просто необходимый фактор. Таковы реалии сегодняшней жизни... сроки уменьшаются, сложность и объем программ постоянно растет, а вот программистов с прямыми руками больше не становится... Да и при наличии прямых рук гораздо приятнее и быстрее работать если знаешь что в случае мелкой ошибки по не внимательности среда тебя сразу ткнет носом, а не устроет феерическое шоу наведенок. C>В теории, третее преимущество позволит управляемой среде разбивать программу на куски и скармливать их в SPU.
И над этими теориями сейчас работают куча ученых. И что-то мне подсказывает что этот алгоритм вполне возможен.
C>Но текущая модель памяти CLR (однородной и бесконечной) этому как-то не способствует.
Да причем тут CLR? Что ты зациклился на CLR? Кто вобще говорит о CLR? Я уже раз 10 сказал что CLR не лучшая основа для управляемой ОС.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Если нам не помогут, то мы тоже никого не пощадим.
Впрочем, я могу путать.
В том то и дело что плохо оно делается... в железе можно эффективно добится изоляции только довольно крупных кусков памяти иначе будет тАкой оверхед что мама не горюй.