Кто-то разбирается в поисковых алгоритмах? Нужна помощь.

Да как угодно. Можно процесс получения адресов останавливать, как только набралось нужное вам количество.

Я написал в вышеприведенной команде : rm -f * . где вы там нашли длинную командную строку?

Ну. и естественно (правда глупо на этом форуме такую ссылку давать - сочтут необоснованными понтами) :

http://www.google.com/search?q=argument+list+too+long

Почитайте, это полезно.

Какие наглые модераторы нынче, причем тут древние ядра? Я говорю не о десятках тысяч файлов. Я говорю о количестве файлов в одном каталоге. И о сотнях тысяч файлов. У вас есть опыт работы с таким количеством файлов? По всей видисости нет. А мой поисковик сейчас имеет в файловой системе больше 2 миллионов файлов. И мои программисты год назад сталкивались как раз с этой проблемой, что ext3 просто не могла по-человечески работать.

Кстати, предлагаю не давить своим авторитетом модератора, и необоснованными заявлениями.

Исходя из вашего поста, я понял, что вы находили пересечение трех массивов , где каждый состоит из 4000 элементов. И это вы делали 1.5 часа? Честно, не верю. Ну или я не знаю на чем это писать нужно 😕

Почему? Зачем вам нужно сразу выдавать все результаты. Можете проанализировать тот же гугль , или более приближенный, и с открытыми исходниками - многосерч. Они выдают и ищут отлько первые 10 результатов. Искать следующие 10 результатов они начинают _ТОЛЬКО_ при нажатии кнопки next. Они никогда не формируют весь result set сразу.

То, что гостевая машина работает быстрее чем реальная? Зря вы так :)

rst, насчет необоснованных заявлений. Все что я пишу - это всего лишь мое мнение, и к модераторству отношения не имеет никакого.

А мнение такое:

"в линуксе 8192 объекта в каталоге - критическое количество для комфортной работы" - это полнейший бред. Для работы нету разницы между 8192 и 8200 например.

Далее, rm -f * - как раз на длину строки с аргументами и ругается. Argument list это, и это не количество, а именно строка - которую bash пытается передать.

Если вы утверждаете, что все-таки проблема rm -f * из-за наличия более чем 8192 файла в каталоге - то почему же rm -rfd ./directory - целиком рекурсивно без проблем удалит хоть 8192 хоть 9500 файлов?

При том что ext3 на современной версии ядра без проблем обрабатывает сотни тысяч файлов в одной директории. Попробуйте, если есть желание.

Я с вами полностью согласен в плане того, что вы написали выше. Но это, на мой взгляд, не противоречит написанному мною. Т.к. то, что вы описали - это и есть "некомфортная работа". И примеров я могу привести много, когда это нужно, но это не получается. Я последние несколько лет как раз работаю с большими количествами информации. И поверьте - частенько приходилось раньше (пока принудительно в ядре не выставил размер окружения большим) тыкаться что-то сделать, и обламываться с воплями Argument list too long и иже с ними.

касательно xfs:

http://www-128.ibm.com/developerworks/library/l-fs9.html

как я делал: беру первый адрес из первого файла, ищу его во втором, третьем... беру второй адрес, третий, четвертый и т.д.

есть вариант пооптимальней?

я не компетентен

но-помоему это уже ЧУШЬ: Гугл и прочие наши вэь-поисковики основываются на принципе не "найди первые 10 соответствий и давай выдачу", а найди ВСЕ соответствия, что для них, имхо, явно вообще проблемы не составляет т.к. далее идет более важная задача - СОРТИРОВКА по релевантности... иначе как вы предлагаете получить наиболее релевантную десятку, не сравнив ее со всеми остальными сайтами? хотите сказать, что топ сразу одним махом выбирается? извольте... 😂

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

он локальный?

и как там организовано все, так как мне предлогали?

знаете. вот сейчас набросал интерсекшен , без какой-либо особой оптимизации.

#include "stdafx.h"

#include <windows.h>

#include <stdio.h>

#include <map>

#include <vector>

using namespace std;



typedef map<DWORD,unsigned short> Tmap_addr;

typedef vector<DWORD> TVec_results;

int _tmain(int argc, _TCHAR* argv[])

{

	Tmap_addr map1;

	Tmap_addr map2;

	Tmap_addr map3;

	TVec_results results;

	srand (GetTickCount());

	DWORD t1=GetTickCount();

	do

	{

		map1[rand()]=0;

	}

	while (map1.size()<4000);

	do

	{

		map2[rand()]=0;

	}

	while (map2.size()<4000);

	do

	{

		map3[rand()]=0;

	}

	while (map3.size()<4000);

	DWORD t2=GetTickCount();

	printf("Time to prepare : %d\n",t2-t1);

	t1=GetTickCount();

	Tmap_addr::iterator i;

	DWORD dwOps=0;

	for (i=map1.begin();i!=map1.end();i++)

	{

		DWORD val=i->first;

		if (map2.end()!=map2.find(val) && map3.end()!=map3.find(val))

		{

			results.push_back(val);

		}

		dwOps++;

	}

	t2=GetTickCount();

	printf ("intersection time : %d\n Intersection result : %d", t2-t1, results.size());

	return 0;

}

У меня сейчас машина : IBM Thinkpad T42p, Intel Centrino 1.7 GHz

результаты следующие :

Time to prepare: 30

Intersection time : 10

Intersection result : 49

Как видите, чтоб найти пересечение 3 массивов мне понадобилось 10 миллисекунд. Так что где-то вы не правильно считаете...

Естественно не все так просто. Но поверьте - это один из принципов. Вы можете посмотреть это даже сами : сделайте запрос по какому-либо слову, где вы будете ожидать, 50 результатов, к примеру. Гугль скажет вам - 50 результатов, и кликните сразу на 5-ю страницу поиска. Гугль вам покажет 3-ю страницу, и скажет, что больше нет страниц. Такое весьма часто встречается. Поэкспериментируйте. Это и яндекса касается и других.

Нет. Переход ring3->ring0 и обратно в случае виртуальной машины - это ОЧЕНЬ ресурсоемкий процесс. Это не 5000 тактов, как на реальной машине. Это НАМНОГО дольше. А работа ядра всегда есть.

Приблизительно так. Мы за базу взяли многосерч. Но помимо этого там еще есть pay per click модуль - вот там приблизительно так организовано.

угу, мне кажется, я даже могу примерно объяснить почему так выходит

но дело не в этом... ну вот сами задумайтесь - как можно определить наиболее релевантную десятку, не СРАВНИВ ее с остальными сайтами? никак 🙅

это вы про *nix говорите? 😕

за пример спасибо, завтра уже проанализирую, просто щас уже настрой не тот, наконец-то собрались, сегодня вечером покидаю родной город и немного покатаюсь по стране :буги_вуги_смайлик: 😂 🍻

ну почему... PR его (ведь вывод основывается на PR ) можно посчитать сразу (при краулинге). Так и делается. После этого отсортировать массивы по PR. А они отсортированны изначально - при краулинге. После этого найти интерсекшен, и опять же отсортировать по убыванию PR. А после этого уже выполнять текстовый поиск по первым 10.. А точнее - пока не наберется 10 результатов.

Как сортировать страницы - поисковик знает заранее. Это определяется PRом. А в вашем случае (если вы дойдете до PR) можно хранить отдельно. И сортировка 4000 ссылок по убыванию PR это будет опять же быстрее чем полнотекстовый поиск.

да без разницы - юних\линух\винда.

на VMWare в ring0 используется JIT компиляция, но все равно ring0 полу-интерпретируемый. В отличии от ring3. А переходы в ring0 есть всегда.

Кстати. сейчас сделал простой текстовый поиск по 450 метрам исходников.

Он выполнился за 1 минуту, на вышеприведенной машине. Так что что-то у вас не то со скоростью.

анализ контента, ссылочное ранжирование, фильтры и прочее - все это в учет не берется, да? тогда это бул бы не Гугл

а PR... это же смешно, говорить что сайт с высоким PR займет высокие позиции это все равно, что смотреть на цифры на счетчике и говорить, что хх% от них это переходы с поисковика

ДА, это было бы вполне закономерно, но это не критерий, это скорее показатель

в общем смысл - один PR ничего не решает, т.к. этот PR может быть проказан ссылками по "запрос1" в то время, как поиск ведется по "запрос2"

имхо

Вы кстати поиск по форуму пользовать не пробовали?

Очень полезная штука, ну а уж кому совсем лень, то читаем http://www.dialog-21.ru/direction_fulltext.asp?dir_id=15539

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