А то препод знакомого попросил ему принести информацию. Мне лично это очень странным показалось, но покопавшись увидел на сайте интэла толи компилятор для бейсика для многоядерок, толи ещё что-то.

Я не в теме на 100%, но если я правильно понимаю суть, то программера на бейсике не должно волновать сколько процессоров будут исполнять его коды. Этож не асм какой-нить.

 

---

Тестирование по РВиннеру.
Мне нравится девушка.
Мне нравится бета.
Значит мы оба из беты!
(с) Firestorm

А что вы думаете, процессор сам будет распаралеливать программу? Ведь это жн не происходит на современных многоядерниках.

Le Merdeur:

А то препод знакомого попросил ему принести информацию. Мне лично это очень странным показалось, но покопавшись увидел на сайте интэла толи компилятор для бейсика для многоядерок, толи ещё что-то.

Для "вижуал бейсика" это может быть и актуально (всё-таки у него там "лиссенеры" какие-то и прочая гуйня, которую нынче принято делать асинхронной).
Для (классического) фортрана слабо себе это представляю - у него понятие стека отсутствует как класс (отчего и нет средств рекурсивности) - как можно асинхронность делать без стека ?

---

Only two things are infinite, the universe and human stupidity, and I'm not sure about the former. ©

Le Merdeur:

А что вы думаете, процессор сам будет распаралеливать программу? Ведь это жн не происходит на современных многоядерниках.

Вы уж определитесь в чем состоит вопрос.

---

Тестирование по РВиннеру.
Мне нравится девушка.
Мне нравится бета.
Значит мы оба из беты!
(с) Firestorm

Риторический вопрос.

 

Сам по себе процессор не может распаралеливать программу, только прогер пишет как ей выделыватся и на каких ядрах(в джаве по крайней мере и ц++).

Для фортрана можно )) и даже под кластеры можно, если использовать библиотеку MPI.

А для бэйсика напрямую нельзя, потому как это интерпретатор.

Le Merdeur:

Риторический вопрос.

 

Сам по себе процессор не может распаралеливать программу, только прогер пишет как ей выделыватся и на каких ядрах(в джаве по крайней мере и ц++).

 

Хм. В нынешних процессорах есть логика которая пытается распараллеливать инструкции выполнение которых независит друг от друга. Насколько эта логика хороша - тот еще вопрос, но то что она есть - об этом читал.

Ни разу не видел, чтобы с С++ можно было указать на каком процессоре должна выполняться программа. Обычно все это уходит на усмотрение операционки. По-крайней мере под линуксом используют стандарт POSIX threads - этот стандарт только позволяет указать какой код пожет исполняться отдельным потоком, конкретной привязки к ядру делать нельзя.

Под виндой, насколько я знаю, та же картина: нити, процессы - пожалуйста.
А вот на какой процессор это будет закинуто - на усмотрение операционки оставляется.
Да и как иначе?
Писать программы ТОЛЬКО под два/четыре/восемь ядер - и пусть "одноядерные" без нее обходятся?

Ulina:

Под виндой, насколько я знаю, та же картина: нити, процессы - пожалуйста.
А вот на какой процессор это будет закинуто - на усмотрение операционки оставляется.

Не совсем так: на современных архитектурах _можно_ указать на каких процессорах будет исполняться процесс (см. CPU Affinity [mask]), но только на уровне процесса (т.е. нити, насколько мне известно, уже "неуправляемы" в рамках заявленного "распределения")

 

Ulina:

Да и как иначе?
Писать программы ТОЛЬКО под два/четыре/восемь ядер - и пусть "одноядерные" без нее обходятся?

Ну, это уже вопросы конфигурации конкретной системы.
Зачем может быть нужно ? - начиная от распределения ресурсов (низкоприоритетные задачи загнать на "дедикейтед ядро" и пусть там "толпятся" ,-)) и кончая управлением "сопроцессов", которые синхронизируются через "мьютексы" (можно снизить латентность реакции по [асинхронным] сигналам).

---

Only two things are infinite, the universe and human stupidity, and I'm not sure about the former. ©