Допустим , мы написали программу, который многопоточно брутит пароли (подбирает). Пример функции потока: Code: //Код C# void TryPasswords(string[] pass,int startIndex,int lenght) { for(int i= startIndex;i<startIndex+lenght;i++) { // if(TryPassword(pass[i])) // WriteToFile(pass[i]); } } // думаю вам понятно для чего параметры функии. Вопрос, если синхронизировать эти потоки ( что бы 2 и более потоки не питались писать good пароли в файл, что бы избежать от File Exception) , то не замедлится ли скорость PPS (пароль/сек) ?? Спасибо за ответ -------------------------------------------------- И если замедлится , то тогда в чем смысл многопоточного брута?
Я предлагаю для начала ознакомиться с понятимями синхронности и асинхронности. ТЫЦ Так же нужно понимать, что асинхронность != многопоточность. Мне кажется вы немного путаете эти обозначения. По поводу записи в файл - основное время будет теряться при работе с файлом, то есть есть смысл заносить в файл не по 1 паролю, а большее количество. Если вы подобрали 100 паролей или аккаунтов, то вы пишите 100 * time_to_open&write. Нежели если вы один раз откроете файл и запишите 100 записей.
Здесь узкий по времени момент - работа с сетью при бруте. При выводе в файл результатов используй буферизацию.
Если пишешь под Windows используй темповые файлы - они автоматически системой скидываются на диск при определенном размере - а до поры до времени это память.
лол. просто ЛОЛ. ачат такой ачат. уже трое дали один и тот же совет, с видами знатоков. смешной совет. Code: class Program { static void Main(string[] args) { Console.WriteLine(Benchmark(WriteLineByLine)); Console.WriteLine(Benchmark(WriteThousandLines)); Console.Read(); } static void WriteLineByLine() { var list = new List<string>(); for (int i = 0; i < 1000; i++) list.Add(Path.GetRandomFileName()); var writer = File.AppendText(Path.GetTempFileName()); foreach (var line in list) { writer.WriteLine(line); } writer.Close(); } static void WriteThousandLines() { var list = new List<string>(); for (int i = 0; i < 1000; i++) list.Add(Path.GetRandomFileName()); File.AppendAllLines(Path.GetTempFileName(), list); } static long Benchmark(Action action) { Stopwatch sw = new Stopwatch(); sw.Start(); action(); sw.Stop(); return sw.ElapsedMilliseconds; } } вот такой тест (тысяча строк, запись по одной строке vs запись сразу всех), вывел 7 и 5 миллисекунд соотвественно. разница в 2 миллисекунды(!). вы потратили в сотни тысяч больше времени на написание ответов. его софт столько времени не потратит на записи в файл за все время своего существования. и не думаю что софт ТСа сможет брутить в огромных количествах, таких чтобы почувствовать разницу. но зато если он будет писать по строке сразу, то он не потеряет данных. а если порциями - то пачка паролей может пропасть. ps преждевременная оптимизация - зло (с) никогда не делайте выводов о производительности кода, не проведя тесты. pss синхронизация забирает времени столько, сколько выполняется код, который находится в крит. секции + еще немного. в-общем все зависит от программиста и его кода опять же.
Это если софт однопоточный, в многопоточном прийдется еще проверять, не пишет ли другой поток в этот файл сейчас. Lock и запись в MemoryStream имхо разумнее, хоть и прийдется выделить еще один поток для сброса данных на диск.
Я соглашусь только в одном - ачат, такой ачат. А остально я хотел бы немного потроллить, думаю никто возражать не будет. Вначале хотел бы затроллить сию строку: Я представляю как бы ты тестировал нагрузки на БД: "А давайте сделаем креш-тест и попробуем записать 1000 записей в бд в течении минуты!" - Оуе! Сервера будут падать на ура! А попробуй-ка сделать такую же запись, только когда софт запилин не тупо под запись в файл, а делает икс операций - ну например брутит в 100 потоков. Да и причём не 1000 записей к ряду, а постоянный дёрг. По поводу разницы всего в 2 милисекунды - вопервых две милисекунды - это 28,57%. Херня ведь правда, особенно если работать не с 1000 строк, а ну скажем в 10°7. На этом можно было бы остановиться - но нет, я потролю дальше. Ну да - магия. Особенно наглядет пример с 1000 строк - они точно "потеряются". Я бы ещё понял если бы речь шла о больших размерах записей. А так, хули, (простите мой францусский) буфер вообще не нужен. Я не слишком толсто троллю? Вы скажите если что. А так идём дальше. Вспомнился сериал "Теория большого взрыва" и фраза Говарда: - "Сергей Андреевич, а долго будет инсталлироваться ВиндоуЗ?" - "Да фигня! Пять минут и ещё немного!" Я надеюсь меж строк прочитали все.
давай код теста. или опять мне писать? можно участок кода writer.WriteLine(line); просто завернуть в lock и все будет видно. ps у меня там кстати ошибка - создание и заполнение списка строк тоже попало в бенчмарк, хотя к задаче отношение не имеет. без этого участка результаты еще лучше. pss ну будешь ты в МемориСтрим писать - проблема потери данных не решится. выключили свет, случайно нажали на кпопку выключения, по каким-либо причинам сдох процесс - и все, сбрученные пароли утеряны. стабильность в работе с данными - гораздо важнее, чем сэкономить 2 миллисекунды, из часа работы софта.
ахах. действительно ты тролль, и не более. если ты работу с файлом переводишь на работу с бд, нам с тобой не по пути. напомню: брут, текстовый файл. Окда? еще раз: тема о бруте. 28% это 28%. принципы оптимизация софта знаете? находим слабое место, его оптимизируем. запись в файл в бруте - не самое слабое место. напомню, необходимо записывать 1000 паролей в секунду, чтобы потерять 2 миллисекунды за одну секунду. тут во-первых, 2 мс в секунду это 0.2% от проц. времени (если даже 1 поток), во-вторых что-то сдается мне что 1000 ппс у ТСа в бруте не будет можно еще эти 0.2% смело делить на несколько десятков раз. кто вас так топорно мыслить приучил. что-то может быть хорошим там, где оно нужно. а где оно не нужно - оно там и не нужно. здесь буффер не нужен. ps ну да, я понял. критику не любим, поймали butthurt, но надо же что-то ответить, пусть и путем отхода от темы и задачи (например в сторону БД) и разведением сферических коней в вакуумных стойлах, попутно язвя, чтобы не было так обидно.
Не вникая в суть задачи, создал бы для каждого потока темповый файл и работал бы в каждом потоке со своим дескриптором. При закрытии открытого дескриптора все данные автоматически из памяти скидываются на диск. За все остальное отвечает сама система. 100 потоков 1000 потоков, скорости не прибавит, а наоборот убавит засечет переключения контекста... число потоков должно ровняться числу ядер.
Не всегда, если есть какието длительные паузы в работе потоков то разница будет даже при большем кол-во потоков чем кол-во ядер, т.к например портоки будут ждать ответа от сервера.
Не понимаю, зачем такой хитрый способ? Достаточно выводить строки с каждого потока в один файл, используя буферизацию. При работе с сетью с помощью блокирующих сокетов прибавит.
2 mironich, Chrome~ при работе с сетью на блокирующих сокетах есть такое понятие как асинхронность (событийная модель) epoll, IOCP. Все зависит от задачи, не буду спорить
2 Chrome~, поторопился я умничать Дабы не вводить людей в заблуждение - действительно для работы с epoll сокеты необходимо перевести в неблокирующий режим.
О_о. Бля такой концерт пропустил, фпезду. ТС, а почему не создать один поток для записи в файл, и передавать в него данные через queue допустим? Никаких эксепшенов, Да и скорость не страдает.
Белый Ворон ну вообще да, без разницы, сразу в файл пишешь или по частям, разницы практически нет, но тут есть другой момент со входом выходом из критической секции, логично было бы по определенном количеству в потоке кэшировать строки, а потом их сразу записывать уже в критической секции. У меня был такой момент на практике, в лог(TListView) около 50-ти потоков записывали информацию, в конечном итоге главный поток конкретно подвисал, пришлось сделать механизм описанный выше.
Jingo Bo у тебя "главный" поток подвисал, потому что TListView работает куда медленнее чем запись в файл это первый момент. а второй момент в том, что простая критическая секция работает намного быстрее, чем TThread.Synchronize
