E__>>На самом деле ситуации, когда от того, отправишь ли мыло прямо сейчас, или через час, очень много зависит, очень, очень редки. Как и ситуации с единым монополистом-провайдером в стране. У нас на работе тоже как-то отрубился инет, а надо было как можно скорее одну штуку в инете глянуть. Подключил телефон да посмотрел. CC>Тут рубанулась вся страна. В телефоне та же фигня.
У Белтелекома что, одна единственная точка подключения к мировому инету? В той же Украние их хватет, причем далеко не все они принадлежат Укртелекому. Конечно, казусы бывают — я помню, как упал канал Донецк-Киев, дык роуты из Донецка на киевские хосты шли через Симферополь, Турцию, Китай и т.д., жесть была.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, Sheridan, Вы писали:
S>Приветствую, sndanil, вы писали:
s>> Full HD Video? Crysis (и еще целая куча игрушек)? S>Так и запишем: для развлечений.
M>Мнэээ. И? HTML с минимум скриптов может оказаться менее ресурсоемким и менее тормозным, чем аналогичный сайт на Silverlight'е. GMail — это, конечно, экстрим, но где гарантия, что аналог на Silverlight'е будет лучше по производительности?
Здравствуйте, koandrew, Вы писали:
K>Именно поэтому я не называл эти блоки отдельными ядрами, а "микроядрами". Это типа как в Cell — одно полноценное ядро + кучка вычислительных.
Ты сам-то по ссылке читал что написано? Это SoC, т.е. не процессор, а целый модуль из нескольких процессоров и периферии. Это примерно то же, чем отличается микропроцессор от микроконтроллера. Да плевать, какой там ЦПУ, судя по описанию, там более одного периферийного процессора в этой системе. Я тебе просто, для развития твоей эрудиции рассказываю, как строят т.н. "аппаратные декодеры видео", чтобы ты в следующий раз ерунду на весь интернет не писал. Понимаешь, в любом случае, какое бы там ядро или даже несколько ядер не было, какая бы система команд не была — это все не принципиально. Принцип построения этих декодеров вовсе не аппаратный, а обычный программный. Я когда-то много лет назад писал на асме для всякой embedded всячины, так что характерно, что последние лет 10 никто даже на асме не пишет. Программы для т.н. "аппаратных декодеров" пишут на языке не ниже чем С, а то и EC.
K>"Зайдя" на плейер по телнету, выяснил, что CPU там MIPS, при этом загрузка его при просмотре фильма в районе нуля, из чего можно сделать вывод о наличии там специализированного процессора для обработки видео. Т.е. ваша теория о DSP не выдерживает проверку практикой — там определённо что-то специфическое.
Да, там более одного периферийного процессора, только как ты собрался с помощью этой информации подтвердить, что мы имеем дело именно с аппаратным декодером?
Или ты не понимаешь, почем один из довольно популярных способов построения цифровых автоматов сейчас называют программированием, и даже выделяют этот способ в отдельную прикладную науку?
K>Опять же практика частично опровергает ваши слова...
Приветствую, Demandred, вы писали:
D> S>Так и запишем: для развлечений.
D> Visual Studio 2010
Гы, чувак, ты понимаешь что это тупо текстовый редактор с подсветкой и дополнительными фичами, которые не работают все время?
То что оно требует дохрена ресурсов — говорит только о известной проблеме с руками разработчиков.
Вот серьезно, сам подумай — зачем IDE столько ресурсов?
D> VmWare Fusion
Ну наконец то.
Молодец, возьми с полки пирожок. Виртуализация — пожалуй единственная фича, ради которой стоило гнать производительность.
Здравствуйте, vdimas, Вы писали:
V>Ты сам-то по ссылке читал что написано? Это SoC, т.е. не процессор, а целый модуль из нескольких процессоров и периферии. Это примерно то же, чем отличается микропроцессор от микроконтроллера. Да плевать, какой там ЦПУ, судя по описанию, там более одного периферийного процессора в этой системе. Я тебе просто, для развития твоей эрудиции рассказываю, как строят т.н. "аппаратные декодеры видео", чтобы ты в следующий раз ерунду на весь интернет не писал. Понимаешь, в любом случае, какое бы там ядро или даже несколько ядер не было, какая бы система команд не была — это все не принципиально. Принцип построения этих декодеров вовсе не аппаратный, а обычный программный. Я когда-то много лет назад писал на асме для всякой embedded всячины, так что характерно, что последние лет 10 никто даже на асме не пишет. Программы для т.н. "аппаратных декодеров" пишут на языке не ниже чем С, а то и EC.
Я очень хорошо представляю, о чём говорю, ибо написание таких прошивок — это одна из моих специальностей в ВУЗе. Возможно, вы не так меня поняли. Я не гвоорил о том, что все операции сделаны "в железе" — так действительно мало кто делает. Но мой поинт был в другом — чтобы декодирование работало с приемлемой скоростью, там должны выполняться аппаратно (или "микроядерно") хотя бы самые тяжёлые операции. Т.е. грубо говоря, разработчик прошивки должен иметь в своём распоряжении "достаточно железа", чтобы он смог запрограммировать его на выполнение задачи.
V>Или ты не понимаешь, почем один из довольно популярных способов построения цифровых автоматов сейчас называют программированием, и даже выделяют этот способ в отдельную прикладную науку?
Я в курсе этого, более того, сам лично занимался программированием PLD и неплохо представляю, что можно сделать на их основе. Но так же мне известно и то, что на их основе сделать нельзя — основная проблем таких схем — это их обычно хреновое быстродействие, потому что "программирование", как правило, не учитывает аналоговые эффекты, связанные со взаимным расположением вентилей, которые иногда капитально убивают быстродействие чипа.
Но всё это не имеет к изначальному вопросу ровным счётом никакого отношения, ибо рассматриваемый чип явно построен по "заказному" маршруту...
Здравствуйте, koandrew, Вы писали:
K>Я очень хорошо представляю, о чём говорю, ибо написание таких прошивок — это одна из моих специальностей в ВУЗе. Возможно, вы не так меня поняли. Я не гвоорил о том, что все операции сделаны "в железе" — так действительно мало кто делает. Но мой поинт был в другом — чтобы декодирование работало с приемлемой скоростью, там должны выполняться аппаратно (или "микроядерно") хотя бы самые тяжёлые операции. Т.е. грубо говоря, разработчик прошивки должен иметь в своём распоряжении "достаточно железа", чтобы он смог запрограммировать его на выполнение задачи.
Что есть "достаточно" железа? Сколько должно быть АЛУ в обычном среднестатистическом современном DSP?
V>>Или ты не понимаешь, почем один из довольно популярных способов построения цифровых автоматов сейчас называют программированием, и даже выделяют этот способ в отдельную прикладную науку?
K>Я в курсе этого, более того, сам лично занимался программированием PLD и неплохо представляю, что можно сделать на их основе. Но так же мне известно и то, что на их основе сделать нельзя — основная проблем таких схем — это их обычно хреновое быстродействие, потому что "программирование", как правило, не учитывает аналоговые эффекты, связанные со взаимным расположением вентилей, которые иногда капитально убивают быстродействие чипа.
Нет, я имел ввиду не программирование вентилей, а программирование как таковое, вплоть до языков сколь угодно высокого уровня. Программируемые матрицы — это малость не то, хотя на них можно собрать автомат, работающий под управлением программы, то бишь процессор. Программируемые матрицы — это аналог "лабораторного стенда" с большим кол-вом вентилей, позволяющий обкатать схемотехнику или же выступать как экономичная альтернатива выпуску микросхем небольшими партиями.
И не надо вводить лишних признаков водораздела, термин "микропрограмма" — это аналог термина firmware, то бишь более точный аналог этого термина — "прошивка". Как пример микропрограммы обычно приводят ПО в сотовых телефонах или BIOS, идущий на материнках. Т.е., если думаешь, что "микропрограммы" исключительно относятся ко временам микропрограммных процессоров, то это не так.
И ты же не будешь утверждать, что службы BIOS, или вот эта его конфигурационная программа, которую можно вызвать на старте, или менюхи в твоем сотовом — это все "железячное" исполнение?
K>Но всё это не имеет к изначальному вопросу ровным счётом никакого отношения, ибо рассматриваемый чип явно построен по "заказному" маршруту...
Короче, никаких аппаратных декодеров видео в природе не существует, и, надеюсь, никогда не появится. Более того, никто не будет ради кодека разрабатывать процессор с 0-ля какими-то мифическими микроядрами, ведь с этим связана еще и разработка tool chain, что может оказаться дороже разработки процессора. Поэтому обычно берут готовое ядро какого-нить обкатанного недорогого DSP вчерашнего/позавчерашнего дня, тоже самое для ЦПУ — обычно берут готовое ядро позавчерашнего дня. Во-первых — дешевле, во-вторых — надежней, в третьих — на современном процессе эту же схему ядра можно заставить работать на более высокой частоте. А другого пути выпускать электронику по разумным ценам и нет. Если под каждый медиаплеер разрабатывать свое ядро DSP, он будет стоить гораздо дороже любого десктопа.
Да, SoC популярны уже более 20-ти лет, ибо позволяют удешевить электронику. Но это ничего не меняет, там такие же циклы разработки ПО, как и везде.
Здравствуйте, Sheridan, Вы писали:
S>Виртуализация — пожалуй единственная фича, ради которой стоило гнать производительность.
Вообще-то, особенности защищенного режима x86-го не позволяют реализовать виртуализацию действительно эффективно. Для сравнения, разработанная около 40 лет назад СВМ для ЕС ЭВМ (полностью советская разработка), могла поддерживать теоретически бесконечную вложенность операционных систем на основе СВМ, ввиду того, что виртуализируемая машина работала практически с той же скоростью, что и невиртуализируемая из-за особенностей архитектуры драйверов и организации управления памятью.
Достаточно сказать, что СВМ умела отображать страницы памяти на несколько независимых процессов в нескольких виртуальных ОС на сколь угодную по счету вложенную виртуальную "матрешку", поэтому использование разделяемых загруженных бинарных образов было весьма эффективное с т.з. использования ОП.
В х86-x64 такое невозможно, поэтому да, остается гнать производительность и расширять адресное пространство.
Здравствуйте, Eugeny__, Вы писали:
E__>У Белтелекома что, одна единственная точка подключения к мировому инету?
У нас белтелеком — единственная точка подключения к внешке.
И сдохло тогда в самом белтелекоме.
Вот такой у нас трындец.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Sheridan, Вы писали:
A>> да, воистину анекдот про сверхнаивность потерял актуальность. давно у нас ядро занимается интенсивными вычислениями с множеством чисел? S>Про криптоапи забыл?
то есть еще и все модули приплетаем?
A>> думаю не сильно ошибусь, если скажу что практически ничего. то что там используется в системной части с управлением кэшированием, быстрыми вызовами и прочим на асме прописано руками. но если надо, могу собрать ядро с нужными опциями и проверить где там тобой перечисленное. S>Это уже интереснее. Давай.
чего давать-то?
объяснишь зачем вот это:
# prevent gcc from generating any FP code by mistake
KBUILD_CPLAGS += $(call cc-option,-mno-sse -mno-mmx -mno-sse2 -mno-3dnow,)
в arch/x86/Makefile?
A>> S>Хотя можешь этого не делать. Я не парюсь и просто выбираю тип процессора в конфигураторе. Мне это совсем несложно. A>> И это говорит человек, который требует от других знать как ОС работает внутри Кстати, выбор в конфигураторе таки влияет, но sse тут не причём. S>Ну так расскажи мне, что там при чем, а я послушаю.
там mtune причём, gcc знает всё же особенности процов, не относящиеся к расширенным наборам команд вроде sse, и пользует их
A>>Кроме того — а ты точно уверен, что оно не будет *медленнее*? S>Я несколько раз наблюдал увеличение производительности и ни разу — снижения.
о, сравнивал значит, ну тогда всё хорошо.
Re[14]: MS больше не будет создавать ПО для Итаниума
Здравствуйте, vdimas, Вы писали:
A>>угу, а еще давай ты расскажешь в каком месте ядру будет лучше от этих -msseX V>Они не только вещественные данные обрабатывают. Отлично подходят для вычисления всяких хешей и контрольных сумм.
а ты собрался в ядре вещественные обсчитывать на FPU/SSE?
расскажи что в make menuconfig сделать чтобы ядро собралось с -msse2/3/... .
Re[15]: MS больше не будет создавать ПО для Итаниума
Здравствуйте, Sheridan, Вы писали:
A>> расскажи что в make menuconfig сделать чтобы ядро собралось с -msse2/3/... . S>Выбрать тип процессора. Компилятору подставляется -mcpu=..., а это в свою очередь включает нужные флаги.
да ну? выбрал, добавилось mtune=core2, а вот про "нужные флаги" я тебе мягко намекнул выше — архитектурный мейкфайл их явно отключает, но всякий случай.
Приветствую, Antikrot, вы писали:
A> A>> да, воистину анекдот про сверхнаивность потерял актуальность. давно у нас ядро занимается интенсивными вычислениями с множеством чисел? A> S>Про криптоапи забыл? A> то есть еще и все модули приплетаем?
Не люблю модули, все в компиливаю в ядро.
A> объяснишь зачем вот это: A> в arch/x86/Makefile?
Объяснений не нашел
A> S>Ну так расскажи мне, что там при чем, а я послушаю.
A> там mtune причём, gcc знает всё же особенности процов, не относящиеся к расширенным наборам команд вроде sse, и пользует их
Ну про mtune я всетаки в курсе.
Здравствуйте, Sheridan, Вы писали:
A>> объяснишь зачем вот это: A>> в arch/x86/Makefile? S>Объяснений не нашел
оно в комментарии написано — чтоб gcc не нагенерил floating point команд. то есть, *чтобы gcc не заюзал эти самые sse*!
FP нефиг в ядре, и хотя действительно в crypto юзается всё вплоть до ускорения aes (sse4.2), оно руками написано и кошерно обрамлено kernel_fpu_begin/kernel_fpu_end.
так что можно до посинения указывать тип процессора в конфигураторе, gcc это никак не поможет с точки зрения sse инструкций.
Re[12]: MS больше не будет создавать ПО для Итаниума
Здравствуйте, Eugeny__, Вы писали:
E__>Здравствуйте, Константин Б., Вы писали:
E__>>>Нужно на каждой машине нстраивать непонятную ненужную фигню. На работе, дома на всех компах на всех системах. А если я хочу не с одного из этих компов глянуть? С компа коллеги, например, потому что мне влом идти на этаж выше за свой комп? У знакомого, к которому я пришел попить пивка? Список этот очень длинный. В случае гмыла мне нужно всего-лишь ввести логин и пароль, и я получу возможность глянуть почту в нормальном клиенте без геморроя с настройкой.
КБ>>И не страшно вот так на всех компах пароль свой оставлять?
E__>Ну, во-первых, я доверяю людям, с компов которых захожу в почту.
Трояны-кейлогеры и у очень хороших людей бывают
E__>Во-вторых, почта у меня дублируется на другой ящик с другим паролем(т.е. я ничего не потеряю в случае чего), а никакого компромата в почте на меня нет, и скрывать мне там нечего. На кой кому-то полгектара совершенно бесполезной для него инфы, я не знаю.
Если этот ящик используется для восстановления паролей то потерять можно ого-го сколько.
Здравствуйте, Eugeny__, Вы писали:
E__>Ну, если это важно. Я лично давно уже не оказывался в ситуации, когда нет возможности выйти в инет.
Мало ты ездишь по просторам нашей страны
.
Если под каждый медиаплеер разрабатывать свое ядро DSP, он будет стоить гораздо дороже любого десктопа.
