Заменить медленные функции Winapi своими

Я тут радикально переделал свой код и теперь он, кажется, стал очень быстрым, но теперь его по-моему сильно тормозят функции WinApi. Как написать свой мьютекс и как обойтись без LocalFree я придумал, а вот как написать свои LocalAlloc и CreateThread пока нет. Может что-то подскажете?

 

что значит кажется?
где ваш тайминг исполенния ДО и ПОСЛЕ?
а чтоб не казалось пить меньше надо

 

Если хочется скорости на многопоточке, то главное понять, что CreateThread нельзя дёргать из принципа "нужен поток - создаём его". Нужно сразу создать столько потоков сколько имеет смысл создавать и общаться с ними передавая им задачи по мере поступления, а когда потоки становятся не нужны - ставить их в режим ожидания критической секции. Критические секции, кстати, быстрее мьютексов, т.к. работают только в рамках одного процесса и потому легковеснее и не сразу в режим ядра проваливаются.

 

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

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

--- Сообщение объединено, 11 сен 2023 ---

 

Мне тут инопланетяни радикально переделали мой генный код и теперь он, кажется, стал очень медленным, но теперь его по-моему сильно разгоняют слоупоки. Как написать свой шеллкодес и как заинжектить его в шелл рептелоедов я придумал, а вот как сконпелировать немного сплоета - пока нет. Не подсказывайте мне ничего - я всё равно ничо не пойму, а если и пойму, то всё равно уже будет слишком поздно.

 

Можно IOCP потоки сделать которые сами будут ждать на вызове GetQueuedCompletionStatus. Передавать задачи через PostQueuedCompletionStatus. Плюсы этого подхода еще в том что много стандартных асинхронных операций в винде можно так обрабатывать.

 

Раньше тайминг был плавным и время обработки соответствовало количеству обрабатываемых данных, но после того, как я сделал создание потоков и выделение 2ГБ рекурсивным, тайминг стал каким-то рваным и время обработки даже увеличилось, а вновь созданный поток завершает обработку данных позже, чем позже, чем поток создавший его, хотя у нового потока в сотни раз меньше данных для обработки. И если бы создаваемый поток быстро обрабатывал и передавал обработанные данные первому, то первый мог бы досрочно вычислить результат и не делать миллионы лишних операций.

P.S. Не известно сколько рекурсий может быть. Зависит от вводных данных.

 

Говорю же - потоки нельзя создавать "по потребности" если важна производительность. Создание потока - очень очень очень тяжёлая операция. Нужно создавать пул из потоков которые спят и ждут приказа на выполнение задачи и после выполнения снова засыпают. Будить их - намного намного намного дешевле, чем убивать/создавать. Особенно если задача высокоинтенсивная, то не нужно больше потоков, чем число ядер на машине, они всё плотно займут и будут молотить на 99% возможного, большего и не добиться. Больше потоков, чем число ядер, имеет смысл только если по задаче значимая их часть проводит время в ожидании выполнения чего то другого - например ввода-вывода, тогда есть смысл в пуле большем, чем число ядер - в оптимуме опять таки чтобы число активно работающих сравнялось с числом ядер.

 

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

 

Llirik, без конкретики и рекомендации будут только самые общие.
Иной код плохо параллелится.

 

@Lirik - пишите свою ОС, раз венда медленная

 

Боюсь, что конкурент воспользуется моей идеей, а мне необходимо победить его, но у него команда, а я один

 

Делаешь - не бойся, боишься - не делай. Иначе покажется, что Вы уже проиграли, да ещё и вынуждаете весь форум проигрывать с каждого второго сообщения

 

Да я и не боюсь) Просто я пошёл по своему неизведанному до селе пути и после полутра годов работы без выходных у меня уже извилин не хватает решить данную задачу (если, конечно, вообще её можно данным способом решить)

 

Простите, вынужден спросить... а этот конкурент... он сейчас здесь? с нами на этом форуме? (с)

 

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

 

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

 

Llirik, т.е. ваш бинарник не уйдет в паблик?
Иначе команда конкурента может проанализировать его.

 

Application, как рыскать везде, чтобы врачи-убийцы не понели, что их обошли и надели белый халат первыми?

--- Сообщение объединено, 13 сен 2023 ---

R81..., возможно, команда конкурента и общается с нами, пока ОП спит или полтора года конпелирует преват. Заказчик же может просто не дожить до исполнителя.