Автор |
Сообщение |
|
|
Заголовок сообщения: |
|
|
|
Pretorian писал(а): И как это поможет например для DOS?
Перезагрузкой сегментных регистров, чтобы смещение кода всегда начиналось с 0.
[quote="Pretorian"]И как это поможет например для DOS?[/quote]
Перезагрузкой сегментных регистров, чтобы смещение кода всегда начиналось с 0.
|
|
|
|
Добавлено: Пн сен 29, 2008 09:39 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
Хищник писал(а): В PC для этого существует аппаратный механизм трансляции страниц, и там можно кусок кода размещать всегда с одного и того же адреса.
И как это поможет например для DOS?
[quote="Хищник"] В PC для этого существует аппаратный механизм трансляции страниц, и там можно кусок кода размещать всегда с одного и того же адреса.[/quote]
И как это поможет например для DOS?
|
|
|
|
Добавлено: Пн сен 29, 2008 09:21 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
Pretorian писал(а): Я же написал зачем, для того что бы кодофайл мог распологаться с любого адреса и был перемещаем, например в кучу. В PC этой потери видно совсем не будет. Зато удобство на лицо.
В PC для этого существует аппаратный механизм трансляции страниц, и там можно кусок кода размещать всегда с одного и того же адреса.
[quote="Pretorian"]Я же написал зачем, для того что бы кодофайл мог распологаться с любого адреса и был перемещаем, например в кучу. В PC этой потери видно совсем не будет. Зато удобство на лицо.[/quote]
В PC для этого существует аппаратный механизм трансляции страниц, и там можно кусок кода размещать всегда с одного и того же адреса.
|
|
|
|
Добавлено: Пт сен 26, 2008 18:31 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
mOleg писал(а): Pretorian писал(а): Тут мысль пришла, хотелось бы развить. Сделать кодофайл перемещаемым в памяти. вопрос только в одном, зачем? Pretorian писал(а): А если сделать так? это приличная потеря производительности.
Я же написал зачем, для того что бы кодофайл мог распологаться с любого адреса и был перемещаем, например в кучу. В PC этой потери видно совсем не будет. Зато удобство на лицо.
[quote="mOleg"][quote="Pretorian"]Тут мысль пришла, хотелось бы развить. Сделать кодофайл перемещаемым в памяти.[/quote] вопрос только в одном, зачем?
[quote="Pretorian"]А если сделать так?[/quote] это приличная потеря производительности.[/quote]
Я же написал зачем, для того что бы кодофайл мог распологаться с любого адреса и был перемещаем, например в кучу. В PC этой потери видно совсем не будет. Зато удобство на лицо.
|
|
|
|
Добавлено: Пт сен 26, 2008 05:46 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
Pretorian писал(а): Тут мысль пришла, хотелось бы развить. Сделать кодофайл перемещаемым в памяти. вопрос только в одном, зачем? Pretorian писал(а): А если сделать так?
это приличная потеря производительности.
[quote="Pretorian"]Тут мысль пришла, хотелось бы развить. Сделать кодофайл перемещаемым в памяти.[/quote] вопрос только в одном, зачем?
[quote="Pretorian"]А если сделать так?[/quote]
это приличная потеря производительности.
|
|
|
|
Добавлено: Чт сен 25, 2008 21:38 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
Тут мысль пришла, хотелось бы развить. Сделать кодофайл перемещаемым в памяти.
В СПФ например вызов словарной статьи из словарной статьи выглядит так:
Код: CALL [CFA]
А если сделать так? Что, при условии вершина кодофайла в ESI. И вершина стека данных не в EAX, а в EBX. Код: MOV EAX,[CFA] ADD EAX,ESI CALL EAX
или если ESI указатель на адрес где хранится начало кодофайла: Код: MOV EAX,[CFA] CALL [EAX+ESI]
Тут мысль пришла, хотелось бы развить. Сделать кодофайл перемещаемым в памяти.
В СПФ например вызов словарной статьи из словарной статьи выглядит так:
[code] CALL [CFA] [/code] А если сделать так? Что, при условии вершина кодофайла в ESI. И вершина стека данных не в EAX, а в EBX. [code] MOV EAX,[CFA] ADD EAX,ESI CALL EAX [/code] или если ESI указатель на адрес где хранится начало кодофайла: [code] MOV EAX,[CFA] CALL [EAX+ESI] [/code]
|
|
|
|
Добавлено: Чт сен 25, 2008 13:50 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
chess писал(а): Ошибка в вашем расчете в том, что при увеличении количества слов растет время поиска для слов в начале словаря. Таким образом при 200000 словах время поиска одного в начале словаря возрастет в 70 раз( у меня в словаре было 3000 слов), поэтому получится 5сек*70=350 сек. Это терпимо если в итоге получится exeшник, но я говорю о другой технологии запуска программ на исполнение и там это не проходит - ждать даже минуту это плохо.
Нет, это не 200 тысяч слов в словаре, это 200 тысяч токенов (далеко не каждый из них создает новое слово). В любом случае, примерно 250 кб грузились в 486DX4-100 не более 15 секунд - это наиболее непроизводительный вариант старого компьютера в цеховой лаборатории, куда ставился проект на Форте. После загрузки каждого из ~20 файлов рисовался квадратик на прогресс баре, и никто ни слова не сказал о времени загрузки. И так понятно, что большие программы долго загружаются.
[quote="chess"]Ошибка в вашем расчете в том, что при увеличении количества слов растет время поиска для слов в начале словаря. Таким образом при 200000 словах время поиска одного в начале словаря возрастет в 70 раз( у меня в словаре было 3000 слов), поэтому получится 5сек*70=350 сек. Это терпимо если в итоге получится exeшник, но я говорю о другой технологии запуска программ на исполнение и там это не проходит - ждать даже минуту это плохо.[/quote]
Нет, это не 200 тысяч слов в словаре, это 200 тысяч токенов (далеко не каждый из них создает новое слово). В любом случае, примерно 250 кб грузились в 486DX4-100 не более 15 секунд - это наиболее непроизводительный вариант старого компьютера в цеховой лаборатории, куда ставился проект на Форте. После загрузки каждого из ~20 файлов рисовался квадратик на прогресс баре, и никто ни слова не сказал о времени загрузки. И так понятно, что большие программы долго загружаются.
|
|
|
|
Добавлено: Сб сен 13, 2008 20:51 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
Хищник писал(а): Имеем около 200 тыс. слов, требующих поиска. Умножаем на 100 тыс. тактов. 20 000 млн. = 20 млрд. тактов, что при тактовой 2 ГГц дает 5 секунд на поиск при загрузке. Это мегабайтный (!) проект. Логотип программы на экран и progress bar...
Ошибка в вашем расчете в том, что при увеличении количества слов растет время поиска для слов в начале словаря. Таким образом
при 200000 словах время поиска одного в начале словаря возрастет в 70 раз( у меня в словаре было 3000 слов), поэтому получится
5сек*70=350 сек. Это терпимо если в итоге получится exeшник, но я говорю о другой технологии запуска программ на исполнение и там
это не проходит - ждать даже минуту это плохо.
[quote="Хищник"]Имеем около 200 тыс. слов, требующих поиска. Умножаем на 100 тыс. тактов. 20 000 млн. = 20 млрд. тактов, что при тактовой 2 ГГц дает 5 секунд на поиск при загрузке. Это мегабайтный (!) проект. Логотип программы на экран и progress bar...[/quote]
Ошибка в вашем расчете в том, что при увеличении количества слов растет время поиска для слов в начале словаря. Таким образом
при 200000 словах время поиска одного в начале словаря возрастет в 70 раз( у меня в словаре было 3000 слов), поэтому получится
5сек*70=350 сек. Это терпимо если в итоге получится exeшник, но я говорю о другой технологии запуска программ на исполнение и там
это не проходит - ждать даже минуту это плохо.
|
|
|
|
Добавлено: Сб сен 13, 2008 19:56 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
chess писал(а): У меня в примере показано, что при словаре Forth (в данном примере это примерно 3000 слов) время на поиск слова близкого к началу словаря ( в примере это DUP ) тратится около 100000 тактов. Учитывая, что наиболее часто употребляемые слова находятся ближе к началу словаря, нужно эту цифру умножить на количество слов в тексте программы.
Берем мегабайт исходников. Допустим, что средняя длина слова - 5 байт (4 + пробел, ориентируясь на ! @ . , но включая и то, что будут и слова большой длины). Имеем около 200 тыс. слов, требующих поиска. Умножаем на 100 тыс. тактов. 20 000 млн. = 20 млрд. тактов, что при тактовой 2 ГГц дает 5 секунд на поиск при загрузке. Это мегабайтный (!) проект. Логотип программы на экран и progress bar...
[quote="chess"]У меня в примере показано, что при словаре Forth (в данном примере это примерно 3000 слов) время на поиск слова близкого к началу словаря ( в примере это DUP ) тратится около 100000 тактов. Учитывая, что наиболее часто употребляемые слова находятся ближе к началу словаря, нужно эту цифру умножить на количество слов в тексте программы.[/quote]
Берем мегабайт исходников. Допустим, что средняя длина слова - 5 байт (4 + пробел, ориентируясь на ! @ . , но включая и то, что будут и слова большой длины). Имеем около 200 тыс. слов, требующих поиска. Умножаем на 100 тыс. тактов. 20 000 млн. = 20 млрд. тактов, что при тактовой 2 ГГц дает 5 секунд на поиск при загрузке. Это мегабайтный (!) проект. Логотип программы на экран и progress bar...
|
|
|
|
Добавлено: Сб сен 13, 2008 19:24 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
реализщация уже существующих быстрых алгоритмов
реализщация уже существующих быстрых алгоритмов
|
|
|
|
Добавлено: Сб сен 13, 2008 16:18 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
chess писал(а): У меня в примере показано, что при словаре Forth (в данном примере это примерно 3000 слов) время на поиск слова близкого к началу словаря ( в примере это DUP ) тратится около 100000 тактов.
Вот, о чем я тоже говорю, нужен новый алгоритм.
[quote="chess"] У меня в примере показано, что при словаре Forth (в данном примере это примерно 3000 слов) время на поиск слова близкого к началу словаря ( в примере это DUP ) тратится около 100000 тактов. [/quote]
Вот, о чем я тоже говорю, нужен новый алгоритм.
|
|
|
|
Добавлено: Сб сен 13, 2008 15:20 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
Хищник писал(а): А мне вот интересно, сколько времени занимает процесс поиска слов при загрузке текста? Это зависит от форт-системы. Вот в СПФ время поиска составляет львиную долю времени загрузки текста. У меня в примере показано, что при словаре Forth (в данном примере это примерно 3000 слов) время на поиск слова близкого к началу словаря ( в примере это DUP ) тратится около 100000 тактов. Учитывая, что наиболее часто употребляемые слова находятся ближе к началу словаря, нужно эту цифру умножить на количество слов в тексте программы. И если учесть, что для большой программы словарь будет гораздо больше, то это довольно таки реальная оценка. Хотя все зависит и от программы, если к примеру наделать слов в начале программы, а дальше использовать в основном только их, то поиск будет гораздо менее время затратным, так как искать надо слова около вершины словаря. Варнак писал(а): Сколько он занимает в процессе загрузки при комиляции совершенно неважно
Ну это зависит от того как использовать транслятор. Вот меня по многим причинам устраивает технология Juice, и одним из ее существенных моментов является отсутствие исполняемых файлов программ. Там есть транслятор и исходники и запуск программы на исполнение идет после трансляции исходников - требования к скорости компиляции и поиску соответственно там очень высоки.
[quote="Хищник"]А мне вот интересно, сколько времени занимает процесс поиска слов при загрузке текста? [/quote] Это зависит от форт-системы. Вот в СПФ время поиска составляет львиную долю времени загрузки текста. У меня в примере показано, что при словаре Forth (в данном примере это примерно 3000 слов) время на поиск слова близкого к началу словаря ( в примере это DUP ) тратится около 100000 тактов. Учитывая, что наиболее часто употребляемые слова находятся ближе к началу словаря, нужно эту цифру умножить на количество слов в тексте программы. И если учесть, что для большой программы словарь будет гораздо больше, то это довольно таки реальная оценка. Хотя все зависит и от программы, если к примеру наделать слов в начале программы, а дальше использовать в основном только их, то поиск будет гораздо менее время затратным, так как искать надо слова около вершины словаря. [quote="Варнак"]Сколько он занимает в процессе загрузки при комиляции совершенно неважно[/quote]
Ну это зависит от того как использовать транслятор. Вот меня по многим причинам устраивает технология Juice, и одним из ее существенных моментов является отсутствие исполняемых файлов программ. Там есть транслятор и исходники и запуск программы на исполнение идет после трансляции исходников - требования к скорости компиляции и поиску соответственно там очень высоки.
|
|
|
|
Добавлено: Сб сен 13, 2008 14:49 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
Хищник писал(а): А мне вот интересно, сколько времени занимает процесс поиска слов при загрузке текста?
Сколько он занимает в процессе загрузки при комиляции совершенно неважно, но иногда кое у кого возникает соблазн воспользоваться готовыми механизмами поиска во время работы приложения, в реальном времени, так сказать ... вот такие вопросы и возникают.
[quote="Хищник"]А мне вот интересно, сколько времени занимает процесс поиска слов при загрузке текста? :shuffle;[/quote]
Сколько он занимает в процессе загрузки при комиляции совершенно неважно, но иногда кое у кого возникает соблазн воспользоваться готовыми механизмами поиска во время работы приложения, в реальном времени, так сказать ... вот такие вопросы и возникают.
|
|
|
|
Добавлено: Сб сен 13, 2008 07:17 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
А мне вот интересно, сколько времени занимает процесс поиска слов при загрузке текста?
А мне вот интересно, сколько времени занимает процесс поиска слов при загрузке текста? :shuffle;
|
|
|
|
Добавлено: Пт сен 12, 2008 23:34 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
chess писал(а): Похоже я все-таки не понял почему это все еще делают, в чем принципиальные трудности. принципиальных трудностей нет. Просто когда Черезов делала СПФ, то решил, что линейного поиска по словарю достаточно. (в остальных русских фортах не так, по крайней мере в тех, что я видел). А вот эксперименты ищут компромисс между сложностью реализации и скоростью поиска. chess писал(а): Вот оценочные прикидки ускорения поиска в моем случае.
были, вроде бы, идеи найденные слова вытягивать поближе к вершине списка, тоже вроде при очень простой реализации прилично ускоряет поиск даже при линейной организации списка. Можно делать бинарные деревья, хотя я таких фортов не видел.
[quote="chess"]Похоже я все-таки не понял почему это все еще делают, в чем принципиальные трудности.[/quote] принципиальных трудностей нет. Просто когда Черезов делала СПФ, то решил, что линейного поиска по словарю достаточно. (в остальных русских фортах не так, по крайней мере в тех, что я видел). А вот эксперименты ищут компромисс между сложностью реализации и скоростью поиска.
[quote="chess"]Вот оценочные прикидки ускорения поиска в моем случае.[/quote]
были, вроде бы, идеи найденные слова вытягивать поближе к вершине списка, тоже вроде при очень простой реализации прилично ускоряет поиск даже при линейной организации списка. Можно делать бинарные деревья, хотя я таких фортов не видел.
|
|
|
|
Добавлено: Пт сен 12, 2008 18:12 |
|
|
|
|