|
|
ru.linux- RU.LINUX --------------------------------------------------------------------- From : Vladimir Bormotov 2:5020/400 25 Aug 2001 18:26:57 To : Eugene B. Berdnikov Subject : Re: Программирование на C и время :-\ --------------------------------------------------------------------------------
Hi, Eugene!
>>>>> "EBB" == Eugene B Berdnikov <berd@desert.ihep.su> writes:
VB>> откуда компилятор узнает, что в данный конкретный момент времени по
VB>>
VB>> if (SomeVar > 0) {}
VB>> else {}
VB>>
VB>> выполняется тот или иной код?
EBB> А откуда об этом узнает "эмулятор", прежде чем займется run-time
EBB> оптимизацией? :)
так он и занимается run-time оптимизацией. Где я сказал что "прежде чем"?
VB>> пить не нужно, нужно внимательно чтитать то, на что отвечаешь. Или я
VB>> просто так называл Cruso/Ельбрус, "для стенки"?
EBB> Вот я пытаюсь понять, просто так написал, или за этим стоит нечто
EBB> содержательное... пока непонятно, т.к. никакой конкретики нет.
что значит никакой конкретики? Hу не знаю я URL'я, где это можно почитать
из первых рук. Мне это рассказывал человек, который общался с людьми из
HP. Может быть он мне вообще "лапши навешал". Hо вроде не должен был.
Поэтому я и сказал "на уровне сплетни".
[skip]
EBB> Hу так я и прошу рассказать. Мне очень интересно, чем интеллект,
EBB> прошитый в кристалле, принципиально отличается от интеллекта,
EBB> выраженного на языке уровнем повыше?
никак, кроме того, что на кристале интелект ОГРАHИЧЕH В РЕСУРСАХ.
EBB> Почему процессор обязан быть ограниченным какими-то своими железными
EBB> ресурсами памяти, и не может пользоваться тем, чем пользуется
EBB> программа?
Еще раз - конвееры у процессора сполне определенной длины. Перегразка
конвеера после перехода - занимает время, т.е. сразу потеря
производительности. Сильно "много" вперед каменный CPU просмотреть не
сможет, и угадать будет ли условный переход или не будет, потому что
прочесть произвольную ячейку памяти для него дорого, опять-же, в плане
производительности. А программе пофиг, потому как это "тот-же самый
уровень".
Это мы рассмотрели только одно узкое место - условные переходы, и
конвееры. А таких "тонкостей" в CPU, где можно выиграть скорость, за
счет наличия дополнительной информации во время выполнения программы
думаю десятки.
EBB> И что такое "всякий навороченный интеллект", принципиально в кристал
EBB> не зашиваемый (это еще ладно), но к тому же в
EBB> компилятор/линкер/rtl/ядро не помещаюийся (финиш, конец света!:).
У компилятора нет реальных данных, которые обрабатываает конкретный
алгоритм.
Возьмем вырожденый пример - мы скармливаем стандартной sort() массив
нулей. Сколько нужно итераций на сортироваку такого массива? Правильно,
"сколько-то нужно" (мне сейчас лениво залезать в Кнута ;). А вот если
знать что там "все нули" - от можно вообще выкинуть вызов sort'а.
Понятно к чему я клоню?
EBB> А про микропрограмное управление мы уже забыли? Hеужто вымерли
EBB> могикане, помнящие, как в процессор VAX перед загрузкой системы
EBB> заливался микрокод?
увы, я Ваксы не застал.
EBB> Ладно, расскажите, чем интересны Crusoe и Эльбрус. Или хоть ссылку
EBB> дайте.
нуу, www.transmeta.com, www.elbrus.ru ?
EBB> Зы. Вспоминаю, как KSI фыркал по поводу их микропрограмных
EBB> достижений... :)
фыркал. Hо, в данном случае, разговор не о том. Я совсем не хочу уходить в
глубь уже процессоров. Я пытался сказать только что "статическая
компиляция" это даже не всегда "лучшая производительность". Пока, в
большинсве случаев, таки да. Hо если вдуматься - то всезде все стараются
так или иначе сделать диманическое связывание, или еще что-нибудь, чтоб
получить бОльшую свободу, как при разработке, так и на этапе выполнения.
--
Bor.
--- ifmail v.2.15dev5
* Origin: BorHomeLand (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /ru.linux/2541fa27d520.html, оценка из 5, голосов 10
|