Проект WSJT-X: моды JT65,JT9,WSPR,JT4,JTMS,MSHV - работа с тестовым софтом - часть 2

[UN7MAU]

А самое главное - это модернизационный потенциал 2011-3 систем: через год-полтора "воткнёте" какой-нибудь Е5-4669v3, который будет к тому времени стоить "копейки"... С X79 вы просто останетесь на месте.
Касательно "Х-каналов памяти" и FT-8: Всё, что нужно для обработки, "крутится" в кэше процессора и скорость памяти на это процесс не влияет. Если память позволяет (32Гб и выше) - можно организовать RAM-диск и на нем держать звуковые файлы JTDX, что полезно во многих отношениях.

[RX4HX]

А самое главное - это модернизационный потенциал 2011-3 систем: через год-полтора "воткнёте" какой-нибудь Е5-4669v3, который будет к тому времени стоить "копейки"... С X79 вы просто останетесь на месте.

Да, вот тоже забыл об этом написать - это тоже очень важный фактор: возможность апгрейта!

[RA3QDP]

Всё, что нужно для обработки, "крутится" в кэше процессора и скорость памяти на это процесс не влияет

А что по этому поводу скажут авторы программы ?

[RX4HX]

А что по этому поводу скажут авторы программы ?

Авторы программы этот процесс не контролируют. Это сама система так делает.

[ES1JA]

А что по этому поводу скажут авторы программы ?

Yes for JTDX speed of memory is less important thing. Pure cpu power is most important. In general memory requirement is relative small. Memory speed is more important to overall work of computer where JTDX is only one task.

[R0JF]

А что по этому поводу скажут авторы программы ?

Да перестаньте вы "попугаями" меряться! 1-2 дополнительных декода? Как академический интерес - да, есть смысл. А на практике - люди на выезде на Athom-525/2Gb RAM вполне себе неплохо работают.

[UI4F]

Вот как надо работать
в 6 потоков

->Скрытый текст<-

а нет, в 7

->Скрытый текст<-

[RA3QH]

Вот как надо работать
в 6 потоков

ALC на полную,да мощи немеряно и то самое получится....

[ES1JA]

Вот как надо работать
в 6 потоков

Nothing connected to computer threads threads, just UB3UAC not correctly tuned setup.

[RA3QH]

Nothing connected to computer threads threads, just UB3UAC not correctly tuned setup.

So what did I write about? It is about setup settings.
You're not quoting my message

[R8CT]

Спасибо за отклик.
Видюха есть - PCIE, 4GB
кулер нашелся похожий на тот, который вы предложили, с рассылкой по РФ.
https://aliexpress.ru/item/400060256...6e193ef3LHCQ9H

Кулер получен за 7 дней от даты заказа.
Доставка курьером.
Мат плату запустил, протестил. Индексы производительности CPU, RAM, 2D, 3D - выше, чем у i7-9700K.
Так что - всё норм (пока).
Мат плата Х79G v3.01 и именно на эту мат плату пока не могу найти мануал.
Интерес к мануалу возник оттого, что на борту есть слот М2, поэтому хотелось бы прочесть об этом.

[RA3QDP]

Авторы программы этот процесс не контролируют. Это сама система так делает.

как именно ? по-подробней, пожалуйста.

[RX4HX]

как именно ? по-подробней, пожалуйста.

А что по подробней? В современной винде программист пишет код, а система + железо его исполняют. Как они его исполняют именно на уровне железа, программист не контролирует по большей части. Это не DOS, где программист мог контролировать 100% выполнение своей программы. Это если коротко.

[RA3QDP]

если коротко

я просил - "по-подробней, пожалуйста".

Конкретно был вопрос - помещается ли в кэш процессора код, который именно декодирует (и требует максимальной производительности) и что поэтому
для декодирования FT-8 скорость обмена с памятью не важна.

[ES1JA]

Конкретно был вопрос - помещается ли в кэш процессора код, который именно декодирует (и требует максимальной производительности) и что поэтому
для декодирования FT-8 скорость обмена с памятью не важна.

Nobody knows, there to many variables. Programmer in general is able to ask what are L2 and L3 cache sizes in current system, but this does not help to much. Using cache is determined only by CPU, not by programmer or even OS. CPU does not know particular part of code executed is from OS or user program. Ability to use cache heavily depends from programming style, C programming style is cache friendly but C++ not. JTDX is written in C++ and fortran. Luckily most of C++ code is written there in C style (using more struct's not classes everywhere), this should be cache friendly solution.
For overall prformance (Lag value) is essential not run other tasks in decoding time, that's why using of some side apps (JTAlert, Gridtracker...) is not recommended as they will rise after having every decode and use cache. In other words when closing those site apps will reduce Lag value significantly then there not enough cache in system. Same is OS differences Win is slower than Nix based OS-s.
Currently best hardware I have seen for JTDX is Apple's M1 cpu.