.Net 2003 c++ оптимизации
9 отговора
519 прегледа
.Net 2003 c++ оптимизации
Абе компилирам си една програма на c++ за компресиране(използва доста шаблони) на .Net 2003 и се оказа че е 2-3 пъти по-бавна от тази която бях компилирал на .Net 2002. Няква важна опция ми се губи явно, идеи! Махнал съм managed extensions. Някой да е имал подобни проблеми?
Re: .Net 2003 c++ оптимизации
по принцип не би трябвало да е по-бавно ако е unmanaged code ... ама ще поразпитам тук там да видя дали няма да ми кажат нещо полезно ... аз съм писал много на С++ ама откакто минах на .нет съм на С# и не знам как стои въпроса с .нет С++ ...
исках да те питам нещо за компресията на данни, по-точно на текст, значи имам огромни текст файлове (GB и нагоре) които се състоят от отделни изречения, примерно като роман. аз трябва да го компресирам този файл, но изречение по изречение, защото трябва да го чета изречение по изречение, примерно трябва да прочета изречение 3423. затова не мога да компресирам целия файл щото не ми се ще за всяко изречение което трябва да прочета да го разкомпресирам и компресирам. значи аз си имам индекси към всяко изречение и мога да го намера чрез random access. та от известно време се чудя каква компресия да ползвам. идеята е че компресиращи алгоритми които работят на принципа на повторенията на патерни или блокове (като зипа примерно) не ми вършат работа щото:
1. в едно изречение я има я няма повторения
2. те правят dictionary което в моя случай ми увеличава размера вместо да го намалява
после си мислех за Huffman codes щото той работи на бинарно ниво и се оказва малко по-ефективен, ама пак си прави таблица, макар и по-малка
накрая се спрях на LZSS, който не прави никакви допълнителни структури ами пази данните в ring bufffer, не е кой знае кво ама компресира горе-долу ...
ти как мислиш, кой алгоритъм ще е най-подходящ за този случай? макар че то има една дузина алгоритми за компресиране на текст и всичко останало са тяхни модификации ...
XM TurboCT .. where comfort meets power
исках да те питам нещо за компресията на данни, по-точно на текст, значи имам огромни текст файлове (GB и нагоре) които се състоят от отделни изречения, примерно като роман. аз трябва да го компресирам този файл, но изречение по изречение, защото трябва да го чета изречение по изречение, примерно трябва да прочета изречение 3423. затова не мога да компресирам целия файл щото не ми се ще за всяко изречение което трябва да прочета да го разкомпресирам и компресирам. значи аз си имам индекси към всяко изречение и мога да го намера чрез random access. та от известно време се чудя каква компресия да ползвам. идеята е че компресиращи алгоритми които работят на принципа на повторенията на патерни или блокове (като зипа примерно) не ми вършат работа щото:
1. в едно изречение я има я няма повторения
2. те правят dictionary което в моя случай ми увеличава размера вместо да го намалява
после си мислех за Huffman codes щото той работи на бинарно ниво и се оказва малко по-ефективен, ама пак си прави таблица, макар и по-малка
накрая се спрях на LZSS, който не прави никакви допълнителни структури ами пази данните в ring bufffer, не е кой знае кво ама компресира горе-долу ...
ти как мислиш, кой алгоритъм ще е най-подходящ за този случай? макар че то има една дузина алгоритми за компресиране на текст и всичко останало са тяхни модификации ...
XM TurboCT .. where comfort meets power
в отговор на шeф нa Coди Дeвня
#3
Re: .Net 2003 c++ оптимизации
Първо да ти кажа че методи от сорта на LZ_* само съм чел за какво става въпрос, никога не съм писал (просто така се е получило трябва някой път да задълбая :))
Хубавото е че даннити са големи и предполагам скороста на компресия не е от значение, докато декомпресията трябва да е бърза.
Наистина можеш да направиш нещо на хъфман от ред да кажем 6-7 (естествено не статично, ще ти трябва някои клонове да ги орежеш ако не носят печалба иначе дървото ще (256 на 7)*х байта) такива алгоритми се държат доста добре върху текстове, така или иначе по-малко от 35-50% докато работиш на ниво байт няма да постигнеш...
Затова като най-лесно що не пробваш да вземеш за азбука не буквите а-я а направо думите от текста (за разделители ползваш интервал и т.н), така азбуката ще стане доста огромна (колко са все пак думите в един език :))което не е чак такъв проблем. Естествено трябва да не те домързи и да не го направиш от нулев ред, защото и думите са зависими една спрямо друга, например след 'искам' е по-вероятно да стои 'сладолед' или 'ъпгрейд' отколото 'колко'. И други методи са подходящи тук, например компресия със субституция, идеята е да заменяш някви фрази с фрази дето ги няма в текста(не се занимаваш с битове). Разкомпресирането е много бързо, а компресията ужасно бавна проблемът е че има страшно много фрази и като решиш да замениш някоя друга (по-кратка която не се среща) разваляш куп други комбинации затова трябва да се мисли няколко хода напред а не да вземеш фразата която се компресира най-добре (пак ще е някакво грииди ама кво да се прави) Всъщност коя фраза с КАКВА да замениш опира пак до хъфман ...
Това са за мен двата варианта и двата не са лесни да се направят.
Първият ми изглежда по-лесен и със сигурност ще дава добри резултати.
Вторият ( със субституциите) - могат да му се правят доста подобрения и мисля че ако някой наистина добър се захване може да ги смачка доста тия текстове, но може би не си струва усилията все пак. И двата имат много общо в основата си, но са тотално различни.
Дано съм успял да те упътя.
Трябва просто да седнеш и да помислиш поне 3-4 дена над въпроса аз за 15-тина минути толкоз мога да ти кажа
Хубавото е че даннити са големи и предполагам скороста на компресия не е от значение, докато декомпресията трябва да е бърза.
Наистина можеш да направиш нещо на хъфман от ред да кажем 6-7 (естествено не статично, ще ти трябва някои клонове да ги орежеш ако не носят печалба иначе дървото ще (256 на 7)*х байта) такива алгоритми се държат доста добре върху текстове, така или иначе по-малко от 35-50% докато работиш на ниво байт няма да постигнеш...
Затова като най-лесно що не пробваш да вземеш за азбука не буквите а-я а направо думите от текста (за разделители ползваш интервал и т.н), така азбуката ще стане доста огромна (колко са все пак думите в един език :))което не е чак такъв проблем. Естествено трябва да не те домързи и да не го направиш от нулев ред, защото и думите са зависими една спрямо друга, например след 'искам' е по-вероятно да стои 'сладолед' или 'ъпгрейд' отколото 'колко'. И други методи са подходящи тук, например компресия със субституция, идеята е да заменяш някви фрази с фрази дето ги няма в текста(не се занимаваш с битове). Разкомпресирането е много бързо, а компресията ужасно бавна проблемът е че има страшно много фрази и като решиш да замениш някоя друга (по-кратка която не се среща) разваляш куп други комбинации затова трябва да се мисли няколко хода напред а не да вземеш фразата която се компресира най-добре (пак ще е някакво грииди ама кво да се прави) Всъщност коя фраза с КАКВА да замениш опира пак до хъфман ...
Това са за мен двата варианта и двата не са лесни да се направят.
Първият ми изглежда по-лесен и със сигурност ще дава добри резултати.
Вторият ( със субституциите) - могат да му се правят доста подобрения и мисля че ако някой наистина добър се захване може да ги смачка доста тия текстове, но може би не си струва усилията все пак. И двата имат много общо в основата си, но са тотално различни.
Дано съм успял да те упътя.
Трябва просто да седнеш и да помислиш поне 3-4 дена над въпроса аз за 15-тина минути толкоз мога да ти кажа
Re: .Net 2003 c++ оптимизации
да де, аз това си го мислех на първо място ама цаката е че това ще работи добре ако компресирам целия файл наведнъж, а аз трябва да ги компресирам изречение по изречение и да ги индексирам така в компресирания им вариант, което може да стане с общо dictionary за целия файл за да има повторения, иначе в едно просто изречение "Аз ям лук", то ще си направи такъв dictionary:
1 Аз
2 ям
3 лук
и ще запише накрая нещо от сорта: [1:Аз|2:ям|3:лук][123], което 2 пъти по-голямо от началното, с общо dictionary ще стане супер и ще се смачка много яко, ама трябва да седна и да го напиша от игла до конец, тоест да преоткрия колелото, а нямам толкова време, знаеш как е, затова ще гледам да взема нещо готово и да го ползвам, сигурно ще се спра на Huffman, щото другите са ми бавни и не постигат добра компресия
мерси за мнението
XM TurboCT .. where comfort meets power
1 Аз
2 ям
3 лук
и ще запише накрая нещо от сорта: [1:Аз|2:ям|3:лук][123], което 2 пъти по-голямо от началното, с общо dictionary ще стане супер и ще се смачка много яко, ама трябва да седна и да го напиша от игла до конец, тоест да преоткрия колелото, а нямам толкова време, знаеш как е, затова ще гледам да взема нещо готово и да го ползвам, сигурно ще се спра на Huffman, щото другите са ми бавни и не постигат добра компресия
мерси за мнението
XM TurboCT .. where comfort meets power
в отговор на шeф нa Coди Дeвня
#5
Re: .Net 2003 c++ оптимизации
хм абе няма ли да ти свърши работа примерно да компресираш на порции по 1 М примерно със стандртен алг., и после да разкомпресираш цялата порция, като си пазиш естествено колко изречения има във порцията
Re: .Net 2003 c++ оптимизации
хм ... хитро ... даже много ... ще го пробвам да видя какъв ще е резулата, но мисля че ще е доста "смачкващ" 
... е ще се наложи да разнасям напред назад (щото то е distributed) още една табица с информацията за чънковете или някъв хедър да направя ... макар че не ми се искаше усложнявам още модела на данни щото той и без това не е много прост и вече става труден за maintanance ... ама май ще се наложи ако искам ефективна компресия ... освен това всичко трябва да работи супер бързо, особено търсенето, така че сигурно няма да са на чънкове от 1М, а по-скоро около 100К, но размера ще се уточни с тестове ... важна е идеята която е много добра
10х
XM TurboCT .. where comfort meets power
... е ще се наложи да разнасям напред назад (щото то е distributed) още една табица с информацията за чънковете или някъв хедър да направя ... макар че не ми се искаше усложнявам още модела на данни щото той и без това не е много прост и вече става труден за maintanance ... ама май ще се наложи ако искам ефективна компресия ... освен това всичко трябва да работи супер бързо, особено търсенето, така че сигурно няма да са на чънкове от 1М, а по-скоро около 100К, но размера ще се уточни с тестове ... важна е идеята която е много добра
10х
XM TurboCT .. where comfort meets power
в отговор на шeф нa Coди Дeвня
#7
Re: .Net 2003 c++ оптимизации
Мойта идея беше речника да е общ за целият текст, това няма да пречи по никакъв начин на индексирането??
просто като прочетеш нещо ще се обръщаш към речника за справка, а ако не е много голям може да го качиш в рамта ...
просто като прочетеш нещо ще се обръщаш към речника за справка, а ако не е много голям може да го качиш в рамта ...
Re: .Net 2003 c++ оптимизации
Начи тъпата trial версия не правила никви оптимизации, как си мислят че ще го пробвам студиото ...
Затова си свалих пълната версия от data.bg
След компилация стана с около 5% по-бързо, направо се изкефих
Сега със сигурност е най-бързата компресия по хъфман от ред 1-ви(само една буква гледа като контекст). Ако някой иска да си я свали - [линк]
Сорса може би ще го сложа някой път още не съм решил ...
Затова си свалих пълната версия от data.bg
След компилация стана с около 5% по-бързо, направо се изкефих
Сега със сигурност е най-бързата компресия по хъфман от ред 1-ви(само една буква гледа като контекст). Ако някой иска да си я свали - [линк]
Сорса може би ще го сложа някой път още не съм решил ...
в отговор на шeф нa Coди Дeвня
#10
Re: .Net 2003 c++ оптимизации
Пробвай чънковете да ги компресираш с Бъроуз-Уилър (google: bwt), за него се предполага че е особено добър за текст.