· Начало · Отвђтить · Статистика · Поиск · FAQ · Правила · Установки · Язык · Выход · WASM.RU · Noir.Ru ·

 WASM Phorum —› WASM.HEAP —› Супер разгон винды! (даже не знаю верить или не верить ;-)

<< . 1 . 2 . 3 . 4 . >>

Посл.отвђт Сообщенiе


Дата: Июн 9, 2004 11:36:02

давайте кто-нибудь возьмётся разработать методику тестирования?, 11 машин на тест у меня есть


Дата: Июн 9, 2004 11:51:27

>UsUf (2004-06-07 17:05:46):
>Вообще если перечитывать статью, то можно заметить >тонкую иронию автора, например в строчках где он пишет >про Микрософт "Нас >беспардонно накалывали много лет. >Теперь пришла наша очередь. " :)))))

>OK (2004-06-07 17:50:48):
>В общем никакого чуда здесь нет!
>Многие наверное не знают, но у nForce2 и у плат 8RDA
>в частности есть один неприятный глюк -
>"плавающие частоты", который как раз сидит
>на таймере ACPI. Суть в том что реальная
>частота проца с включенным ACPI прыгает и
>понижается под нагрузкой - факт известный.
>При отключении ACPI частота проца становиться
>номинальной, отсюда и греется он сильней.
>А 3DMark 2003 – 4246 marks для 9600 это
>нормальные попугаи кстати для такой системы.
а зачем марк использовать?, мы же не видеоподсистму тестируем

результаты
http://book.heliopark.ru/test/


Дата: Июн 9, 2004 18:15:33

Мда :(((
Печально. Ладно.
Спасибо, ZENiTH!


Дата: Июн 9, 2004 18:54:04

> http://book.heliopark.ru/test/
> Печально. Ладно.
а что вы хотели?
каким боком здесь завалялась пропускная способность памяти?
непонятно как вообще мультимедийный тест прошел. MMX-регистры при переключении контекста в 486-hal'е не сохраняются (вот сейчас только что проверил), так что при запуске двух MMX-программ ждите ластов.
реально ускоряется реакционная способность на возникновение прерываний, скорость переключения задач, работа с дымом (dma) и pci.
запустите любой тест (неважно какой) и создайте X потоков, нет, X мало, лучше Y, а затем сравните результаты с разными ядрами ;)
я сейчас как раз такими экспериментами занимаюсь, и могу сказать что разрыв в производительности _уже_ обнаружен, однако, было бы наивно ожидать, что смена hal ускорит работу мультимедийных команд или увеличит таковую частоту памяти ;)
тут еще кстати приходится воевать с этим гребанным PnP, т.к. для достижения достоверности результатов и исключения побочных эффектов, хочется назначить устройствам одни и те же IRQ, а новое ядро упрямо развешивает все по-своему ;((


Дата: Июн 9, 2004 18:58:51

нет, X мало, лучше Y

Хороший анекдот. Всегда мне нравился :)

я сейчас как раз такими экспериментами занимаюсь

Хорошо. Напиши потом сюда, плиз, свои рекомендации.


Дата: Июн 9, 2004 19:45:59 · Поправил: kaspersky

> Хорошо. Напиши потом сюда, плиз, свои рекомендации.
давайте начнем с того, что вспоминим функции hal'а.
я могу навскидку назвать следующие:
программирование контроллера прерываний и управление прерываниями;
обслуживание портов ввода/вывода;
синхронизация ЦП;
синие экраны смерти;
отладка ядра;
драйвера нижайшего уровня;
работа с DMA;
работа с счетчиками производительности;
управление шиной и девайсами (это верно для 486, но потом управление девайсами было внесено из hal'а в ntosknrl.exe и прицеплено к PnP, причем довольно монстроузным образом)

теперь. берем кренел профайлер из ddk и смотрим куда такты идут? пускаем на системе, в которой играет винамп, работает сеть, крутиться видео, копилируется проект, словом все _реально_ загружено. смотрим, кто у нас больше всего жрет такты. оказывается:
20   166         ntoskrnl.exe InterlockedIncrement 0x08040078C 12 4
51   425         ntoskrnl.exe InterlockedDecrement 0x080400798 12 4
252     4        ntoskrnl.exe ExReleaseResourceForThread 0x0804644BC 5610 4
35   291         ntoskrnl.exe READ_REGISTER_ULONG 0x080455F50 12 4
264    48        hal.dll HalSetProfileInterval 0x080062E5C 548 2
19777   251      hal.dll HalSetRealTimeClock 0x0800675F4 7860 2
Total context switches     75349


вклад остальных намного менее значителен.
вот от них и нужно плясать ;)
тут это... кто хорошо знает перл, чтобы сделать анализ отчетов профайлера? чесно говоря руками разгребать его лениво, а писать парсер на Си нет времени.

вот еще одна методика измерений: запускаем большое кол-во потоков, каждый из который все свое процессорное время тратит на увеличение некоторого счетчика (или вычисления ариметических операций, не суть важно каких), очевидно, что чем меньше времени раходуется на переключение контекста, тем больше намотает счетчик за одно и тоже время.


Дата: Июн 9, 2004 19:52:07

"тут это... кто хорошо знает перл, чтобы сделать анализ отчетов профайлера"

Я знаю неплохо. Что нужно?


Дата: Июн 9, 2004 20:03:22 · Поправил: kaspersky

> Я знаю неплохо. Что нужно?
анализатор логов kernprof.exe - чтобы выдирал оттуда имя функции, кол-во вызовов, кол-во времени исполнения, а затем усреднял данные 10-20 логов, отбрасывая крайние значения, и позволял их сравнивать с логами, полученными на другом ядре.
хотя и так видно, что основное время уходит на спинлуки, вызываемые халом из ntoskrnl, ну и на переключение контекста.
с 486 ядром мы имеем примерно в полтора раза больще переключений контекстов на 733 MHZ P-III


Дата: Июн 9, 2004 20:35:54

У мя пока не стоит ДДК - все руки не доходят поставить. Профайлера у мя этого, соответственно, тоже нет. Приаттачь сюда лог какой-нибудь, я на него посмотрю.
Пока, предварительно.
1) Создать хеш массивов. Как ключ хранить имя функции. Как значения хранить кол-во вызовов и время исполнения.
Это выглядит (очень приблизительно) так:
my %functions;		#hash table with collisions
my @data;					#function name + function time + number of calls

while(<LOG_FILE>)
{
	#parse by tab 
	@data = split /\t/;
	unless (exists $functions{$parsed_func_name})	
	#function name doesn't exist in the hash - create record
	{
		$functions{$parsed_func_name} = [@data];
	}
	else
	#function name exists in the hash - collision - add time + number of calls
	{
		$functions{$parsed_func_name}->[0] += time;
		$functions{$parsed_func_name}->[1] += number of _calls;
		#etc...
	}	
}


Дата: Июн 9, 2004 21:35:17


Дата: Июн 9, 2004 21:39:04 · Поправил: kaspersky

вот сейчас закончил пробежку по знакомым.
впечатления следующие: на догигагерцовых ЦП с SDR ускорение при переключении задач заметно "визуально" и работать с виндой намного комфртнее, причем разница тем существеннее, чем медленее проц и тормознее память;

на пост-гигагерцовых ЦП с DDR разницы (визуально) никакой нет, а тестировать профилировщиком не было возможности, да и смысла тоже.


Дата: Июн 10, 2004 13:45:56

Проверено лично на P1.0/128sd и A1700+/256ddr. На обоих даже не проводил тестов - на глаз прирост производительности в 2-2.5 раза (на атлоне поменьше, чем на пне). А при убиении всего ненужного - визуализаций, всяческих процессов и т. д. - просто летает. Сбоев пока не было. WinXP Pro Rus 2002.


Дата: Июн 10, 2004 13:49:09 · Поправил: semen

ГЫ: Значит надо самим оптимизировать HAL, чтоб и с MMX/XMM все было ОК и летало.
Еше в догонку: никто не пробовал отключать Perfomance Counters на обоих Hal`ах? Отключить можно Exctrlst.Exe из PSDK


Дата: Июн 10, 2004 15:29:50

> Отключить можно Exctrlst.Exe из PSDK
отключить - можно, но нужно ли?
они сильно упрощают девелопминг...


Дата: Июн 10, 2004 19:32:09

kaspersky

Крис, вот тело скрипта. Он не обрабатывает все, что ты просил, т.к. я не знаю назначение всех колонок :(
use strict;

my %functions;	

while(<*.txt>)
{
	open(LOG, $_) or die;
	while(<LOG>)
	{
		if($_ =~ /\s+[0-9]+\s+[0-9]+\s+[a-zA-Z.]+\s+([a-zA-Z]+)\s+[0-9xA-F]+\s+([0-9]+) /)		
		{
			unless (exists $functions{$1})
			{
				$functions{$1} = $2;
			}
			else
			{
				$functions{$1} += $2;
			}
		}
	}
	close(LOG);
}

foreach (keys %functions)
{
	print "Function is $_\t Number of calls is $functions{$_}\n";
}

<< . 1 . 2 . 3 . 4 . >>


Powered by miniBB 1.6 © 2001-2002
Время загрузки страницы (сек.): 0.085