Путь просветления

[FireFenix]

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

1) Использую WMI для получения информации об оборудовании и его параметрах (процессор, память, видяшка и сетевые карты). Для получения всей инфы трубуется ~4 секунды. Есть ли боле ебыстрые методы обнаружения присутствующих устройств (даже если они временно отключены, вплане программно)? или WMI считается расово-верным решением получения инфо о системе?

2) У меня в компе стоят 2 сетевухи. При выполнении ipconfig получаю вагон сетевых интерфейсов, из которых только 2 - мои сетевухи. Откуда берётся этот хлам и что он там делает?

Код: Выделить всё

C:\Users\Fenix>ipconfig

Windows IP Configuration

Ethernet adapter Home: - подключение по 1ой сетевухе
[вырезано]
Ethernet adapter Internet: - подключение по 2ой сетевухи
[вырезано]
Tunnel adapter isatap.{F124FC82-4DA3-47BE-AF8D-A95F881BCCA8}:
[вырезано]
Tunnel adapter Local Area Connection* 12:
[вырезано]
Tunnel adapter isatap.{C19E0E27-577E-4834-9293-02B660407614}:
[вырезано]
Tunnel adapter 6TO4 Adapter:
[вырезано]
Tunnel adapter Reusable Microsoft 6To4 Adapter:
[вырезано]
Tunnel adapter Local Area Connection* 9:
[вырезано]
Tunnel adapter Local Area Connection* 11:
[вырезано]
Tunnel adapter Local Area Connection* 13:
[вырезано]
Tunnel adapter Local Area Connection* 14:
[вырезано]
Tunnel adapter Local Area Connection* 15:
[вырезано]
Tunnel adapter Local Area Connection* 16:
[вырезано]
Tunnel adapter Local Area Connection* 19:
[вырезано]
Tunnel adapter Local Area Connection* 20:
[вырезано]
Tunnel adapter Local Area Connection* 21:
[вырезано]
Tunnel adapter Local Area Connection* 22:
[вырезано]
Tunnel adapter Local Area Connection* 23:
[вырезано]


3) Существует ли золотая середина количества потоков на процесс? Т.к. у меня самый многопоточный процесс - system (в Win7), у которого 111 потоков. То сейчас я беру в среднем ~100 потоков на процесс. Плохо ли это?
К примеру проектирование серверных приложений, приложений для перебора паролей и т.д.

4) Рационально ли в серверном приложении под каждого юзера выделять отдельный поток? Или оптимальнее делать очередь задач на всех юзеров и распределять на некоторое количество потоков?

5) Как я понимаю, DirectX выступает как прослойка между хардварным уровнем системы и приложением, в конечном счёте отвечающая за работу с видеокартой и системным бэкбуффером. Интересно, дало бы профит в производительности для .NET приложений, если DX был бы полностью перенесён на .NET?

[Хакер]

1. Есть более быстрые, но они не такие универсальные, как WMI. Информацию о процессоре и видеокарте придётся получать совершенно разными путями. Впрочем, зависит и от того, какая информация необходима.
2. Кто-то насоздавал (система или софт какой).
3. Не существует. Существует (индивидуальное ограничение) для каждого процесса — в АП процесса должны найтись свободные регионы (с учётом фрагментации кучами, файл-маппингами (включая загруженные модули) и просто приватными блоками страниц, включая уже созданные стеки) для резервирования стеков для всех потоков. В физической памяти и файлах подкачки должно хватить места для выделения (но не резервирования) всех стеков всех процессов в системе — это уже общесистемное ограничение.
   
   Большое количество потоков процесса system — это особый случай (в силу того, что сам процес system — особый случай). Обычно каждый драйвер для каждого PDO/FDO может создавать системный поток (вызовом PsCreateSystemThread). То есть для каждого физ. устройства — поток, для всех надстекованных над ним логических устройств — тоже, возможно, поток.
   
   

   Плохо ли это?

   
   Если всех 100 потокам нужны одни и те же данные, то это лучше намного, чем 100 процессов с 1 потоком плюс IPC. Даже если IPC делается через файл-маппинги.
   
4. Рационально всегда использовать потоки там, где нужно обеспечить параллельность.
   
5. Как прослойка между прикладным программистом и драйверами видеокарты. DirectX к сожалению к счастью не может быть переписан на .NET, по крайней мере весь, потому что часть его живёт и функционирует в ядерном окружении.

[Antonariy]

2) Это примочки для IPv6. Можно его отключить и выполнить netsh int isa set state disabled и они пропадут.

[FireFenix]

Спасибо за ответы!

2) Это примочки для IPv6. Можно его отключить и выполнить netsh int isa set state disabled и они пропадут.

Пропали только интерфейсы isatap, а вот вагон Tunnel adapter Local Area Connection* xx остались

Кто-то насоздавал (система или софт какой).

Я думаю просто больше нечему их создать, кроме как софту или системе
Только вот в основном софт обозначает свои интерфейсы, к примеру как VirtualBox VirtualBox Host-Only Network, да и кроме антивируса (NOD32) больше нету сетевого софта.
Осталось выяснить - зачем понадобилось системе...

Есть более быстрые, но они не такие универсальные, как WMI. Информацию о процессоре и видеокарте придётся получать совершенно разными путями. Впрочем, зависит и от того, какая информация необходима.

В конечном счёте хотелось бы реализовать, что-то похожее на полное инфо о системе, как аналог Евереста, HwInfo и подобных, без готовой БД к серии устройств.
Как я понимаю они используют свой драйвер для получения информации.
Каким образом они её получают?

Не существует. Существует (индивидуальное ограничение) для каждого процесса — в АП процесса должны найтись свободные регионы (с учётом фрагментации кучами, файл-маппингами (включая загруженные модули) и просто приватными блоками страниц, включая уже созданные стеки) для резервирования стеков для всех потоков. В физической памяти и файлах подкачки должно хватить места для выделения (но не резервирования) всех стеков всех процессов в системе — это уже общесистемное ограничение.

Плохо ли это?

Если всех 100 потокам нужны одни и те же данные, то это лучше намного, чем 100 процессов с 1 потоком плюс IPC. Даже если IPC делается через файл-маппинги.

Да, это понятно, что количество потоков может быть ограничено доступной памятью.
Но мне интересно целесообразность создания некоторого количества потоков, при котором системное время не распределялось в основном только на переключение потоков или не приводило к полному зависанию системы.
Я так полагаю, что ещё нужно отталкиваться от суммарного количества потоков и возможностей системы. Тока вот каким образом?

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

Тут вопрос в другом.
Предположим, я хочу написать брутфорс паролей по алфавиту... Тут понятно, многопоточность - даст прирост в производительности.
Я хочу оставить на некоторое время этот процесс (скажем наночь), то какое количество потоков даст наибольший profit?

Как прослойка между прикладным программистом и драйверами видеокарты. DirectX к сожалению к счастью не может быть переписан на .NET, по крайней мере весь, потому что часть его живёт и функционирует в ядерном окружении.

Гугл мне мало поведал о структуре ДХ
Судя по моим наблюдениям и импорту функций, дх является прослойкой между пользовательским уровнем и драйверами.
Ну и сама идея: .NET медленно работает с вызовом функций из нативных длл и некоторым количеством копирований памяти внитри/из ДХ. Т.е. сделав (не полная замена, а просто как альтернатива для .NET приложений) Managed библиотеку удовлетворяющую функциям ДХ, то получим некоторый профит.

6) Искал контрол для удобного отображения информации о работе потоков... Понравился прогресс бар из utorrent'a.
Как они реализовали заполнение прогресс бара линиями?
Алгоритм к которому я пришёл, это - просто создавать холст изображения размером с прогресс бар и в нужной позиции отрисовывать линию или же холст с заданным размером, а его ширина отдаётся на масштабирование контролу.
Может есть эффективнее и рациональнее методы заполнения?

[Хакер]

Каким образом они её получают?

Никогда не интересовался.

Но мне интересно целесообразность создания некоторого количества потоков, при котором системное время не распределялось в основном только на переключение потоков или не приводило к полному зависанию системы.

Ну, если сервер обслуживает всех клиентов созданием потока для каждого, вместо того, чтобы, например, использовать пул из 10 потоков для 10 клиентов, а остальных ставить в очередь, то такой сервер имеет смысл запускать на многопроцессорной системе, потому что при том же числе потоков число переключений будет меньше во столько, сколько процессоров/ядер имеется.

Тут вопрос в другом.
Предположим, я хочу написать брутфорс паролей по алфавиту... Тут понятно, многопоточность - даст прирост в производительности.
Я хочу оставить на некоторое время этот процесс (скажем наночь), то какое количество потоков даст наибольший profit?

Вот это эталонный пример того, где многопоточность не нужна. Она нужна только если ты хочешь взломать 10 независимых паролей, которые и проверять можно независимо (пока проверяется совпадение для первого, можно в это же время проверять совпадение для девятого) — тогда есть смысл в 10 потоках.

Ну и сама идея: .NET медленно работает с вызовом функций из нативных длл и некоторым количеством копирований памяти внитри/из ДХ. Т.е. сделав (не полная замена, а просто как альтернатива для .NET приложений) Managed библиотеку удовлетворяющую функциям ДХ, то получим некоторый профит.

Никакого профита не получим: необходимость dotnet→native шлюзов никуда не пропадёт, просто они опустятся на уровень ниже. Так твой дотнетное приложение вызывает нативный DX, а так дотнетному DX придётся вызывать нативное ядро и нативные драйверы. Не профит, а большой проигрышь, потому что, мне думается, число вызовов, которые делает DX к драйверам и ядру, на порядок больше числа вызовов, которое делает твоё приложение к DX-у.

6) Я не знаю, какой прогресс-бар у изображения, и не знаю, что такое «холст» (GDI такого объекта не имеет). Я настаиваю на использовании стандартного прогресс-бара.

[iGrok]

Вот это эталонный пример того, где многопоточность не нужна. Она нужна только если ты хочешь взломать 10 независимых паролей, которые и проверять можно независимо (пока проверяется совпадение для первого, можно в это же время проверять совпадение для девятого) — тогда есть смысл в 10 потоках.

Обычно она всё же применяется, но только тогда, когда есть возможность действительно параллельно проверять результаты.
Тогда просто перебираемое пространство делится на количество потоков, и каждому выдаётся своя часть.

Думается мне, для подобной задачи оптимальным кол-вом потоков будет равное кол-ву процессоров/ядер. Возможно, при более детальном исследовании задачи/условий и оптимизации, умноженному на два (гипертрединг).

[Хакер]

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

Может быть и применяется, но смысла нет никакого.

Параллельно проверяет же не поток-переборщик. Так что нет смысла делать многопоточный брутфорс.

Скажем, если это веб-сайт, который требует ввода пароля, то проверять правильность будут потоки на сервере. В этом случае брутфорсеру нет смысла иметь много потоков, достаточно одного, который отсылает пачку запросов на сервер и ждёт результатов. Эта пачка запросов на сервере распределится по потокам (если вообще распределится, а не встанет в очередь на обработку одним потоком). Если это локальное приложение, требующее ввода пароля, одно приложение не сможет одновременно проверять несколько паролей. Придётся запускать несколько экземпляров. У каждого будет по одному GUI-потоку, который, скорее всего, и будет делать проверку. И в этом случае опять же брутфорсер должен быть однопоточным: шлёт пачку WM-сообщений всем окнам разных инстансов и смотрит на результат.

[iGrok]

Может быть и применяется, но смысла нет никакого.

Параллельно проверяет же не поток-переборщик. Так что нет смысла делать многопоточный брутфорс.

Ну, я имел в виду, например, буртфорс пароля по хэшу, брутфорс пароля к архиву, и т.п.
В общем, все случаи, при которых правильность вычислений можно проверить не отходя от кассы.

[Хакер]

В общем, все случаи, при которых правильность вычислений можно проверить не отходя от кассы.

Это значит проверить арифметически, при помощи одних только циркуля и линейки процессора и памяти. В этом случае имеет смысл распределить на число потоков, равное числу логических ядер, да. Но, опять же, если подумать, распараллеливается не сам брутфорс, не перебор, а процедура проверки. То есть она как бы не специфична для брутфорса.

[iGrok]

Но, опять же, если подумать, распараллеливается не сам брутфорс, не перебор, а процедура проверки.

Хмм.. Ну да. Точно.
Распараллеливается не перебор (чё его распараллеливать-то?), а вычисления и проверка.

[FireFenix]

В общем, все случаи, при которых правильность вычислений можно проверить не отходя от кассы.

Это значит проверить арифметически, при помощи одних только циркуля и линейки процессора и памяти. В этом случае имеет смысл распределить на число потоков, равное числу логических ядер, да. Но, опять же, если подумать, распараллеливается не сам брутфорс, не перебор, а процедура проверки. То есть она как бы не специфична для брутфорса.

Наверное я плохо выразился, но я это и имел ввиду.
Что при взломе хеша брутфорсом - мы перебираем пароли и хешируем. Для получения профита мы разбиваем на несколько потоков, в которых производим хеширование

Ну собственно в этой или похожей ситиуации: 2 потока - вроде мало... 100 - вроде много... а сколько оптимально?

6) Я не знаю, какой прогресс-бар у изображения, и не знаю, что такое «холст» (GDI такого объекта не имеет). Я настаиваю на использовании стандартного прогресс-бара.

Стандартный прогресс бар отображает только единственное значение, а хотелось бы получить аналог

Единственное что пришло в голову - сделать в виде обновляющегося PictureBox'a. Т.е. мы берём создаём пустую картинку некоторого размера и отрисовываем вертикальные полоски.

[Хакер]

Что при взломе хеша брутфорсом - мы перебираем пароли и хешируем. Для получения профита мы разбиваем на несколько потоков, в которых производим хеширование

Если взлом не пароля, а хеша, перебором входных последовательностей до совпадения выходной с эталонной, то есть смысл в потоках только если компьютер многопроцессорный, а число потоков при в этом случае нужно сделать равным числу процессоров, желательно выставив Affinity Mask.

Ну собственно в этой или похожей ситиуации: 2 потока - вроде мало... 100 - вроде много... а сколько оптимально?

Неужели совсем не чувствуешь?

[FireFenix]

Что при взломе хеша брутфорсом - мы перебираем пароли и хешируем. Для получения профита мы разбиваем на несколько потоков, в которых производим хеширование

Если взлом не пароля, а хеша, перебором входных последовательностей до совпадения выходной с эталонной, то есть смысл в потоках только если компьютер многопроцессорный, а число потоков при в этом случае нужно сделать равным числу процессоров, желательно выставив Affinity Mask.

Возможно я скажу бред...
Мы выбираем количество потоков по количеству ядер, т.к. это нам даёт гарантированное одновременное исполнение потоков.
Но на каждый поток выделяется квант времени, и в системе работают не только мои потоки => мои потоки не всегда будут пролазить в очереди среди не самых важных процессов.
Т.е. добавляя потоки, тем самым увеличиваем суммарное время работы данного процесса

Ну собственно в этой или похожей ситиуации: 2 потока - вроде мало... 100 - вроде много... а сколько оптимально?

Неужели совсем не чувствуешь?

Тут дело такое... Опытным путём и методом тыка для моей 2х процессорной системы без HT (точнее win показывает 2 ядра, хотя проц и его серия Smithfield идут с HT. И возможность включения не наблюдал) получается где-то 4-8 потоков, когда диспечер показывает на 100% и получается наибольший profit.

[Хакер]

Но на каждый поток выделяется квант времени, и в системе работают не только мои потоки => мои потоки не всегда будут пролазить в очереди среди не самых важных процессов

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

В общем, тут надо работать с приоритетами, а не давить количеством.

[Денис]

Единственное что пришло в голову - сделать в виде обновляющегося PictureBox'a. Т.е. мы берём создаём пустую картинку некоторого размера и отрисовываем вертикальные полоски.

Нормальный метод, я так раньше и делал. Главное, полоски отрисовывать в процентах от общей длины контрола и желательно через API

[FireFenix]

Но на каждый поток выделяется квант времени, и в системе работают не только мои потоки => мои потоки не всегда будут пролазить в очереди среди не самых важных процессов

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

В общем, тут надо работать с приоритетами, а не давить количеством.

А если мы работаем асинхронно с ~100 сайтами, которые парсим регулярными выражениями.
Тогда если предположим, что квант времени = 10мс, а получения контента с сайта = 200мс, то для эффективной работы нужно ~[20 * 2 * количество ядер] потоков?
Т.е. идея в том чтобы, пока часть потоков ожидает контент, другая часть - уже обрабатывала данные в этот момент. [20 * 2 * количество ядер] в идеальном случаем, когда всё время идёт на мои потоки, а так наверное получается ~[20 * количество ядер] потоков
Если да, то возможно ли подсчитать, сколько ли выделяется времени на поток?