Разница между OMP_NUM_THREADS и OMP_THREAD_LIMIT [duplicate]
Вы можете использовать функцию numpy.eye.
import numpy as np
def one_hot_encode(x, n_classes):
"""
One hot encode a list of sample labels. Return a one-hot encoded vector for each label.
: x: List of sample Labels
: return: Numpy array of one-hot encoded labels
"""
return np.eye(n_classes)[x]
def main():
list = [0,1,2,3,4,3,2,1,0]
n_classes = 5
one_hot_list = one_hot_encode(list, n_classes)
print(one_hot_list)
if __name__ == "__main__":
main()
Результат
D:\Desktop>python test.py
[[ 1. 0. 0. 0. 0.]
[ 0. 1. 0. 0. 0.]
[ 0. 0. 1. 0. 0.]
[ 0. 0. 0. 1. 0.]
[ 0. 0. 0. 0. 1.]
[ 0. 0. 0. 1. 0.]
[ 0. 0. 1. 0. 0.]
[ 0. 1. 0. 0. 0.]
[ 1. 0. 0. 0. 0.]]
3 ответа
Это правильная реализация OpenMP и игнорирует изменения в среде изнутри программы. Как указано в стандарте OpenMP 3.1, стр. 159:
Изменения в переменных среды после запуска программы, даже если они были изменены самой программой, игнорируются реализацией OpenMP.
Вы выполняете именно то, что сказано в этом параграфе.
OpenMP позволяет изменять такие параметры только через функции
omp_set_*, но нет такой функции для потока -limit-var ICV:Однако настройки некоторых ICV могут быть изменены во время выполнения программы OpenMP с помощью соответствующих директивных предложений или подпрограмм OpenMP API.
Я думаю, вы можете использовать
num_threadsпредложение#pragma omp parallelдля достижения желаемого.
Изменение поведения OpenMP с использованием OMP_THREAD_LIMIT (или любой другой переменной среды OMP_*) невозможно после запуска программы; они предназначены для использования пользователем. Вы можете заставить пользователя вызывать вашу программу через скрипт, который устанавливает OMP_THREAD_LIMIT, а затем вызывает вашу программу, но это, вероятно, не то, что вам нужно сделать в этом случае.
OMP_NUM_THREADS, omp_set_num_threads, и предложение num_threads обычно используются для установки количества потоков, работающих в регионе.
-
1Нет, ты прав. Моя ожидаемая аудитория будет иметь ограниченное понимание переменных окружения, и я бы предпочел, чтобы программа была максимально простой в использовании. Что касается omp_set_num_threads и num_threads, это не является постоянным. Я хотел использовать OMP_THREAD_LIMIT как постоянное статическое значение, которое я мог бы применить к вложенным параллельным разделам, чтобы убедиться, что все доступные потоки были использованы наиболее эффективным образом, поскольку бросали все в первую параллель и затем не имели свободных потоков для второго (вложенная) параллель редко является самым быстрым способом. – Dess 9 September 2013 в 12:13
-
2Я вижу, что вы имеете в виду, но я все еще не думаю, что
OMP_THREAD_LIMIT, вероятно, будет лучшим решением на практике. Если вы возьмете десять равных кусков работы, а затем разделите два из них пополам, это вряд ли улучшит производительность, потому что наихудшие потоки все еще так же медленны. Если ваш алгоритм эффективно выполняет какую-то балансировку нагрузки, тогда вы можете также использовать вызовы omp_set_num_threads, чтобы явно определить, какие потоки будут разделены во вложенной области. – Sean Patrick Santos 11 September 2013 в 01:58 -
3Я делаю что-то подобное. Если исходная параллель принимает 10 итераций, она будет использовать 1,2,3,4,5 или 10 потоков, в зависимости от того, сколько из них доступно (так как любое другое число не будет уменьшать количество общих проходов параллельно). Оставшиеся потоки будут использоваться во вложенной области (где число, если итерации могут сильно варьироваться). В этой второй области потоки присоединены к самым большим последовательностям итерации. Однако необычно, что любой из них был бы в три раза больше остальных и, следовательно, потребовал бы более одного потока для поддержания темпа. – Dess 11 September 2013 в 10:15
Это может быть оффтопным, но вы можете попробовать openmp collapse вместо ручной работы здесь.