Четверг, 21 Ноября 2024, 22:21

Приветствую Вас Гость

[ Новые сообщения · Игроделы · Правила · Поиск ]
  • Страница 2 из 2
  • «
  • 1
  • 2
Затирание данных перед освобождением
SaiteiДата: Воскресенье, 30 Июля 2017, 12:46 | Сообщение # 21
старожил
Сейчас нет на сайте
Vuvk,
тык
тык

Код
    // By using tasks explcitly.
    public static void DoTree<T>(Tree<T> tree, Action<T> action)
    {
        if (tree == null) return;
        var left = Task.Factory.StartNew(() => DoTree(tree.Left, action));
        var right = Task.Factory.StartNew(() => DoTree(tree.Right, action));
        action(tree.Data);

        try
        {
            Task.WaitAll(left, right);
        }
        catch (AggregateException )
        {
            //handle exceptions here
        }
    }

(код выше просто показывает как работает thread pool в C#)

пысы: попробуй все же использовать thread pool. Суть в том, что необходимое количество потоков УЖЕ создано и готово к обработке информации.
giperionДата: Воскресенье, 30 Июля 2017, 12:48 | Сообщение # 22
участник
Сейчас нет на сайте
Ты не уловил.
Ускорять данную задачу с помощью многопоточности - (если у вас там не 1 млн. элементов) точно не стоит :) . В С++ для быстрого доступа по ключу для контейнеров типа ключ/значения используют unordered_map (и я не только про STL вариант, но и вообще). В С тоже неплохо бы что то такое заимплементировать.
Просто создавать и удалять потоки динамически - ересь похуже многопоточного поиска.


Skype: sergej_1965
VuvkДата: Воскресенье, 30 Июля 2017, 12:52 | Сообщение # 23
заслуженный участник
Сейчас нет на сайте
Цитата Saitei ()
попробуй все же использовать thread pool. Суть в том, что необходимое количество потоков УЖЕ создано и готово к обработке информации.

Интересненько. Почитаю на досуге про это.
Цитата giperion ()
Ускорять данную задачу с помощью многопоточности - (если у вас там не 1 млн. элементов) точно не стоит

Я пришел к такому же выводу, потому что и тысяча с трудом наберется.


Сообщение отредактировал Vuvk - Воскресенье, 30 Июля 2017, 12:54
SaiteiДата: Воскресенье, 30 Июля 2017, 12:52 | Сообщение # 24
старожил
Сейчас нет на сайте
from https://stackoverflow.com/questions/8423873/parallel-binary-search
Код
You can easily use parallelism.

For k is less than n processors, split the array into n/k groups and assign a processor to each group.

Run binary search on that group.

Now the time is log(n/k).

There is also a crew method that is logn/log(k+1).


Просто тебе тогда придется хранить дерево в массиве
giperionДата: Воскресенье, 30 Июля 2017, 12:58 | Сообщение # 25
участник
Сейчас нет на сайте
Saitei, лол, ты воспринял тему с мультипоточным поиском в контейнеру очень серьёзно, я посмотрю.
Вы же не Google и не Amazon чтобы какие то контейнеры таким образом оптимизировать :)


Skype: sergej_1965
VuvkДата: Воскресенье, 30 Июля 2017, 17:48 | Сообщение # 26
заслуженный участник
Сейчас нет на сайте
Saitei, задача не только быстро искать, но и быстро добавлять/удалять элементы. Так что массив не катит.
giperion, если что-то можно сделать надежнее/быстрее, то почему бы и нет.


Сообщение отредактировал Vuvk - Воскресенье, 30 Июля 2017, 17:48
giperionДата: Понедельник, 31 Июля 2017, 04:47 | Сообщение # 27
участник
Сейчас нет на сайте
Цитата Vuvk ()
если что-то можно сделать надежнее/быстрее, то почему бы и нет.

Приоритет задач. Отвлекаясь на эту задачу, ты отвлекаешься от создания новых фич которые будут намного заметнее чем то что ты делаешь.
Далеко не факт, что твоя оптимизация с контейнером является наиболее эфективной


Skype: sergej_1965
  • Страница 2 из 2
  • «
  • 1
  • 2
Поиск:

Все права сохранены. GcUp.ru © 2008-2024 Рейтинг