Трябва ми инсталация на Qt 5.5.x + MinGW 64-битова версия. В www.sourceforge.net намирам разни
проекти, обаче или са изоставени или Qt 4.x , а не ми се компилира цялата библиотека, че отнема
доста време.

Официално на сайта им х64 са с визуалното и не ми тръгват. Незнам дали не могат да се изкомбинира инсталацията на визуалната и да се пренастрои да компилира с MinGW-то?
Евентуално да си я разработваш на 32-бит и да я прекомпилираш на края за 64

To 5.6 излезнало ?

Windows Host
Qt 5.6.0 for Windows 64-bit (VS 2015, 836 MB) (info)
Qt 5.6.0 for Windows 32-bit (VS 2015, 840 MB) (info)
Qt 5.6.0 for Windows 64-bit (VS 2013, 836 MB) (info)
Qt 5.6.0 for Windows 32-bit (VS 2013, 840 MB) (info)
Qt 5.6.0 for Windows 32-bit (MinGW 4.9.2, 1.0 GB) (info)
Qt 5.6.0 for Android (Windows 32-bit, 1.1 GB) (info)
Qt 5.6.0 for Windows RT 32-bit (VS 2013, 1.0 GB) (info)
Qt 5.6.0 for Windows RT 32-bit (VS 2015, 1.0 GB) (info)

И на мен ще ми е интересно - благодаря

Какво значи x64 с визуално ?

На мен и 32-бита ми върши работа, но забелязох следното: програма с Qt 4.7.0, обработваща няколко милиона записа (всеки запис е един текстов ред с няколко 32-битови или 64-битови числа) се изпълнява в release за 121 секунди, с Qt 5.5.1 release се изпълнява за 181 секунди, при debug времената са съответно 4m:20s vs. 7m:33s. Реших да използвам Qt 5.5.1 че Qt Creator е по-нов и дебъгването ми харесва повече, но пък много бавно всичко. Помислих си да не би защото процесора и ОС са 64-битови, а Qt програмата е 32-бита и затова да се бави толкова, но с 32-bit Qt 4.7.0 програмата е с 49% по-бърза. Май няма да се окаже причината в битовете на процесора/ОС. Но все пак ми се ще да я пусна в 64-битов вариант, за да видя дали ще има някаква разлика.

Аха, сега захапах, че "визуално" било VS Нямам VS нито пък искам да имам, така че трябва да копам с MinGW. Довечера ще изпробвам на няколко Linux машини, с различни версии на Qt да видя дали и там Qt 5.x.x е такова бавно.

За 64 битови числа би трябвало да има голяма разлика ако се обработват с 64 бит програма. Но съответно трябва да си спазил съответните изисквания:
- Да са подравнени на 8 байта (64бит)
- Да е оптимизиран за тези сметки - ако използваш плаваща аритметика, не се използва аритметичният копроцесор, а мултимедийните инструкции.
- Ако ги пуснеш към видеокартата - OpenCl ще е още по-безкрайно бързо
Общо взето при тестове съм бил доволен от компилираните с MinGW програми, не съм пробвал х64.
Ако не са тайна и искаш- дай примерни числа и сметките, които да се направят?

Не са подравнени на 8 байта и са цели числа, но вътре на места ги конвертирам
до плаваща за временни сметки и после пак в цели числа. Входният файл е hex-decimal trace файл,
чета го ред по ред в QString, след това с QString.simplified.split() до QStringList, вадя целите числа,
обработка и записвам изхода в CSV файл. Като цяло не е нещо кой знае колко сложно, затова
ме учуди, че отнема толкова време. Но пък и записите са 4-5 млн. реда.

Засега успях на QtCreator 3.5.1 от Qt 5.5.1 да му закача Qt 4.7.0 версията с неговия си GCC компилатор и
така дебъгвам. Преди време бях качил една 64-битова инсталация на Qt 5.3.x и работеше, но в края
на миналата година ми сложиха Win7, но забравиха да ми сложат по-голям HDD. Вече 3 месеца чакам
по-голям харддиск, че тия 160GB за нищо не стигат.

Правих нещо подобно за редакция на вестник.
Според мен ползваш бавни функции. Аз си действам по традиционният начин с масиви.
Но работя на Паскал и е доста по-бръз за стрингове. А и файловият трансфер май.

Направих следния експеримент: замених QString с char там където се въртят най-много цикли, ефектът
е незабелижим, от 2m:40s програмата се забърза на 2m:38s, т.е. QString са го оптимизирали достатъчно
добре, че да е почти толкова бърз колкото стандартните char [].

Чак пък да е много по-бърз Паскал при работа със стрингове , не е. Само когато търсиш дължината
на стринг, и то ако е по-малък от 255 байта. Мисля при по-големи стрингове минаха
на концепцията на C/C++ за null character. Понякога кодът на C може да стане забележимо по-бавен
ако да речем се използва следната конструкция:

наместо:

Но това е много относително, ако компилатора е читав и char *s не ти e volatile, тогава
само веднъж смята дължината на стринга, наместо на всеки цикъл.

В случая с Qt проблема е от Qt 5.x.x, инсталирах 64-bit Qt 5.3.2 на 64-bit OS, пак е
толкова бавен кодът, както и 32-bit Qt 5.3.2 на 64-bit OS. Обаче 32-бит Qt 4.7.0
е два пъти по-бърз на същата 64-битова OS, така че прекратих експериментите, засега ще използвам
в това приложение 32-bit Qt 4.7.0

Дай някакъв пример да го пробваме
И дългите стандартно си ги пази с поинтер+дължината процесорна дума. Но не е в началото на низа, както при късите стрингове, които сега се обявяват изрично.
Тотал командера на новите хардове правеше непрекъснат трансфер на дълги файлове 174МБ/с срещу 154МБ/с за стандартният виндоус експлорер. Но проблемът може и да си е в М$
Да не говорим и че е 8 битов- и на 64 бит виндос не допуска над 255 байта път+име..?

То е име на файл, не е увод на роман...

¶ дай един пример да го пусна на 5.6 32bit.

Не мога току така да дам пример, поради съображения от естеството на работата.
Входният файл е вече над 1GB записи във формат на PCAN Explorer trace файл,
това е log файл от работата на едно устройство за една седмица със sample rate
100ms. Мога евентуално да помисля за подобни аритметични операции, но ще ми
отнеме време. Примерно генерира се 1GB файл със подобни записи, след това
се чете ред по ред, правят се няколко сметки и резултата се принтира в изходен
CSV файл, накрая се прави 2-ри CSV файл, в началото на който се принтират
крайните резултати от алгоритъм, след това към 2-рия файл се прилепва
същинския CSV файл със сметките върху отделните записи.

Няма ли някъде performance test на Qt framework ? Може би ще е по-удачно нещо
такова, въпреки че най-вероятно ако има ще е предназначен за тестване на
графическите възможности, докато при мен няма графика - просто конзолно
приложение, използващо QString, QStringList, QDir и подобни класове. Но разликата
между Qt 4.7.0 и Qt 5.x.x е очебийна, просто е невероятно колко Qt 5.x.x е по-бавен.
Като намеря време ще направя една сравнителна таблица на времената за изпълнение
на всички версии на Qt които имам.

Не е необходим твоя файл. Кажи какво има в него: например 5 колони с данни, смята се сума на нечетните и се добавя квадрата от сбора от другите две. Ще направя файл със случайни числа, стрингове или там каквото е необходимо. Не знам дали стана ясно каква е идеята.

Да де- и на мен това ми беше идеята с генерирани данни да се работи.
Работех в редакция и обработвах голям брой текстови файлове за търсене на информация и ставаше доста бързо.

5.6 LTS 16 March 2016,

Явно съм бил прав, че в Qt 5.0.x - Qt 5.5.x нещо са били загрузили със стринговете. Сега използвам
Qt 5.7.0 и според мен QString е с около 10% по-бърз от Qt 4.7.0

Другото, за което се чудя, май излиза, че всичките MinGW x64 + Qt 5.x.x и подобни инсталации предлагат 64-битов GCC, но използват 32-битова компилация на Qt.... Някой да е съумял да компилира 64-битов Qt Framework за Win64 (наблягам на framework, не app) ? За Win32 разбрах къде/какво да пипна и
се получи, но mkspecs за Win64 не намирам, а в този за win32-g++ изрично е записано WIN32. Не че ми трябва
конкретно, но ще ми е интересно, ако някой гуру знае как се бае на Qt за да стане Win64