>> i8080 -- это азы, но к реальной жизни имеет уже весьма смутное
>> представление, поэтому сейчас речь идёт только о 386+.
> Да как сказать? Годы шли, а общие идеи в основе работы микропроцессоров
> никуда не делись. Развили хорошо. Не вижу революции. Вычисления на GPU могли бы на них претендовать, но пока слишком мало кардинальнвх отличий. ИМХО, введение кеша, конвейера, страничной адресации и механизмов защиты -- это было последним существенным шагом, и не самым простым, как для реализации, так и понимания.
> Пример того что я считаю профессионализмом электронщика: в эпоху первых пентиумов и
> PCI, один человек, посмотрев на USB, сказал что в будущем будут
> рулить скоростные последовательные шины с дифференциальным сигналом, похожие по смыслу.
) Я вообще не понимаю, зачем был сделан USB, когда был более чем работающий COM. Что мешало просто поднять частоту обмена? А протокол обмена, косящий под сетевые фреймы был известен уже очень давно под именем "Модбас" и ему подобных. Тысячи их. А крепление COM мне на порядок больше нравится, чем USB (ну, по крайней мере -- в производстве)
>> pyPC -- это исключительно химерный компьютер рождённый моей головой. Поэтому ни КВМ,
>> ни ВиртуалБокс его никогда не запустят. В-общем, в этом вся затея.
> Пусть ОС в гуесте
> знает что это - виртуализатор. И использует драйвер, который умеет сбагривать
> I/O на хост короткими и быстрыми путями. Это называется virtio. В
> результате оно разогналось до скоростей сравнимых с реальной железякой, перестав быть
> забавной игрушкой.
Да я в курсе как виртуализация построена. У самого Ulteo и coLinux постоянно вертятся.
Идея моего виртуального писюка именно в том, чтобы не иметь ничего общего с реальным писюком. Вопрос быстродействия важен, но он не дороже информационной безопасности.
> По поводу таких оптимизаций в серьезно настроенных виртуализаторах сдулись даже севые,
> но не оптимизированные в эти направления виртуализаторы по типу bochs. Они
> были неприемлимо тормозными, про них при удобном случае все забыли.
Бочка для разрабов и параноиков. Не для виртуализации, имхо задачи стоят несколько другие.
>> будь здоров.
> А это сколько процентов от производительности host? KVM может более 90% при
> счете и доступе к памяти, сохраняя все плюсы виртуализатора.
От производительности host машина будет давать в лучшем случае 25%. Но дело не в производительности. Мне и 200 млн. оп. на одном ядре хватит. Цель не стоит сделать повтор того ,что уже есть. Смысл? Цель стоит создать реализацию ПК, который будет заведомо безопасен, изолироваться от возможного большого брата и иметь возможность переносить системы с оси на ось, с ЦП на ЦП. Python такую возможность даёт непосредственно. Си, Паскаль, ассемблер -- заставят посуетиться чуть больше, или намного больше.
> Не знаю что есть "методом timeit", но в целом часто дергать запросы
> "сколько времени?"
+0,5%
> в процессе бенчмарков в тугом цикле не следует, а
>Да и первый вопрос который возникает: что бенчмаркано и зачем?
> Какие-то реально существующие программы оптом выполняют подобный код? Нормальные бенчмарки
> или пытаются забенчмаркать какой-то общий аспект работы системы (например, "скорость доступа
> к памяти") или пытаются прогнать какой-то практически-значимый алгоритм (например, "сколько
> времени займет хеширование 10 мегабайтов с использованием sha-1?"). А по такому
> коду не понятно что являлось целью бенчмарка. Доказать всему миру что
> "питон не тормозит ну хоть где-то"?
Первоначально идея была поюзать во FreePascal стандартную либу mmx. Для этого надо было включить парочку опций компилятора. После нескольких отчаянных попыток из официального руководства, дебаггера и нескольких часов времени понял, что реально юнит сделан криво, и абсолютно никакого прироста производительности нет. Я решил посмотреть как это сделано в других ЯП. В Си есть (по ассемблерному листингу) небольшая оптимизации по передаче параметров и работе со стеком в ходе вычислений. Почему Visual Bsic 6 пилит наравне с Си через рантайм, а cython уделал чистый Си я не разбирался, но могу предположить, что в случае VB6 идёт предварительная оптимизация вызовов (может трансляция в .NET по тихому?), а в случае с cython более удачные заготовки использованы для замещения python-кода + какие-то оптимизирующие ключи, о которых я не знаю?...
В любом случае, сравнивать sha-1, i/o и т.п. -- смысла нет. python не проигрывает Си в таких вещах. Просто не может. Т. к. юзает компиленные сишные модули. То же самое касается и системных обращений -- они зависят от системы и в других моментах такие же тонкости.
В итоге что остаётся тестировать?
Кстати! Как-то писал zip-архиватор на python+cython. Таки на упаковке "Василия Тёркина" при (я надеюсь) одинаковом исходном алгоритма моя тулза паковала сильнее на 3...7% и быстрее почти вдвое, чем 7-zip!!! Правда памяти хавал раза в 1,5...2 раза больше.
