Изпечатай

[vektorman]

Здравейте, замислих се над този въпрос, понеже в сферата на образната диагностика, където работя, напоследък съм свидетел на огромни разлики по отношение на скоростта на софтуера. Получава се така, че малка програма, създадена от никому неизвестна полска фирма, с размер на инсталатора 6мб, бие по скорост и лекота на работа ВСИЧКИ други комерсиални и некомерсиални програми които съм виждал, като ВСЯКА от другите е от много, до стотици или хиляди пъти по-бавна и по-голяма от нея. Става въпрос за https://www.radiantviewer.com/ Нямам друга причина да им правя реклама, освен тази, че съм удивен. Освен че е супер лека и интуитивна програма, работи и на най-бавните и стари компютри, така сякаш са току що купени от магазина и то ако не по-бързо то поне със същата скорост в сравнение със специално нагодени фирмени работни станции, чиято цена не ми казват, даже да посмея да питам. Почти всички мои колеги в цялата страна, освен софтуера който им е предоставен, по практически причини се принуждават да си инсталират и RadiAnt за да могат да си вършат работата. Програмата не е никак евтина ако трябва да я купуваш цялата, но най-важните и функции могат да се ползват безплатно до безкрайност. Не знам на какъв език е писана, но много подозирам Асемблер.
Та въпроса ми е, възможно ли е да е ОГРОМНО съотношението в скоростта и размера на програмите между С и Асемблер, или има и други фактори в цялата работа.

[go_fire]

Фактора винаги е един. Какво точно върши програмата. От потребителска гледна точка може да изглежда едно и също, но при едното да се правят хиляди различни неща, а при другото например две. А щом говориш нещо за скъп, специализиран хардуер, то си говорим за мениджмънт висша класа, което значи, че по задание е било нещото да е тежко, тромаво, за да има нуждата от този хардуер.

Отговора на другия ти въпрос е, че според асемблеристите наистина Ц е безкрайно бавен език. Но това едва ли има общо с тази, конкретна ситуация. А освен това добри писачи на асемблер се намират трудно. Почти всички програмисти бягат от този език.

[remotexx]

Без изходния код, можем само да фърляме боб, но дам и аз мойте 5 бобени зрънца...

Има два варианта или Голиат е толкоз тромав щото се е нагрухал с екстри дето не му трябват почти никога и на никой, но така за тежест и за надуване на цената или Давид не работи със същите алгоритми ами ползва значително по-добри.

В днешно време асемблера не е предимство а недостатък - пример:
Програмата (да кажем видеокодек) е компилирана и оптимизирана на асемблер и за SSE2 33 бита  и макар че компа на който се пуща има SSE5 не може да го ползва и върви бавно в сравнение с , от другата страна напр. имаме същия алгоритъм но напр. С#, това нещо е компилирано само до междинен код и runtime средата по време на изпълнение ще го компилира до нативен (JIT compiler) 32 или 64 бит (асм 32 няма да тръгне на 64) като ще ползва и ССЕ6 ако има или когато се появи т.е. ще бъде оптимизирано точно за машината на която се изпълнява. Да не говорим че ИИ т.е. оптимизатора ще намери оптимизации дето никой човек няма да се сети или па няма да му се прави на ръка напр. loop unroll на цикъл 1 до 100

За пример за алгоритмични шорткъти напр.тука
https://stilman-strategies.com/content/primer.html

https://stilman-strategies.com/content/advantage.html

Че и кратка история са дали - учудвам се че поляците нямат никаква подсказка на сайта как точно го правят или никой не знаеше полски, а?. Малко като с картината Ленин в Полша 

https://stilman-strategies.com/content/history.html
Случайно попаднах на Стилмън и не е с цел реклама, и понеже наскоро една завеждаща личен състав беше пуснала обява че търсят С++, Стилмън също търсят, даже много по-добре обясняват какво точно търсят, който му е интересно може да изгледа и няколкото филмчета с демонстрации да види как се справя софтуера им.
https://stilman-strategies.com/content/demos.html

[4096bits]

Според мен причината е точно в това, че единият е Голиат, а другият Давид.

Предполагам, че Голиат не си е писал сам почти нищо от софтуера. Поръчал го е. И го е поръчал евтино, като единствените основни изисквания сигурно са били просто да работи и да е лъскаво. Една планина допълнителни функции, които може да се ползват веднъж в годината, но пък които оправдават цената и допълнително тежат на некадърно написаната програма. Не е толкова до алгоритмите, защото трудно бих нарекъл алгоритъм да направиш нещо поедин или друг начин. Без всъщност да оптимизираш нищо. Като например да ползваш if/else или два if.

Докато другите пишат, тестват, пишат, тестват, докато повече не могат да измислят, как да го направят по-добре. И естествено - продават. Когато не си си оставил ръцете, а си вложил труд, време, сърце каквото и да  сътвориш, няма начин да не ти го купят.

Програмата предполагам обработва данни и ги показва на дисплея. Не е задължително да е на асемблер за да е бързо. Може дори да е на Питоня. Сега сигурно ще се изхилят някои от вас, но има библиотеки точно за тази дейност. Писани на С. Но най-вероятно въпросното програмче е писано на C#.

Асемблер се ползва много, където наистина е нужна скорост. Вграждат го и в С програми. Отделни функции или нещо от този сорт.

[jet]

Някога просто се затъва във фреймуърки от един в друг и кода става километри (те затова браузърите смучат ГБ).

Или се прави SQL заявка:
  select * from <table>
(т.е. цялата таблица се вдига в масив без никакво или много широко условие) и после с цикъл се обикаля масива да се отсеят нужните записи.

Неоптимизирани цикли.

Обектното програмиране е по-бавно от процедурното.

Джавата е всеизвестна със "скоростта" си.

Многото излишно писане/четене по диска , отваряне и затваряне на един и същ файл на всяка итерация от цикъл. Някакви излишни и тежки проверки в цикъл.

Викане на външни програми в цикъл.

[remotexx]

Чак сега забелязах те това било само визуализатор някакъв...
1. Универсален инсталатор пък ЕХЕ - ами Мак, Линукс? разбирам да е джава па то... ЕХЕ
2. аз DICOM viewer съм виждал и на Джава - разбираемо бавен
3. Не казват това онлайн или офлайн инсталатор е - виждал съм как 100-тина МБ Вижуал Студио инсталер дърпа и инсталира 4 ГБ
4. Яките фремуърци т.е. бавните конкуренти явно си пущат редкатора и като вюър само че блокират реадктиращите функции - поради което стават яко бавни
5. Зачетох им сайта - явно имат некои оптимизации - колкото ядра набарат - ползват си всичките, колкото памет набарат - ползват я всичката, а другите (както каза джета) явно всеки път отварят файловете и зареждат от диска (като не се събира целия във видео паметта, която е доста по-малко от RAM), а другите вероятно повечето памет я изяжда (кода на) функциите за редактиране които са блокирани 

[vektorman]

Всички други които съм ползвал и с които го сравнявам също са визуализатори и вършат същото. И ги сравнявам на едни и същи компютри. ЕХЕ-то докато го стартираш и след има няма 5 секунди вече си го инсталирал. Не знам за това време колко гигабайта може да изтегли. Единия от вюърите които ползваме на работа (не искам да споменавам имена) тегли всички изображения от сървъра в папка на харддиска и с него разглеждаме образите, но когато едно изследване се състои от много такива, например над 1000 изображения и има лаг при превключване между съседните изображения, става много тегаво. Затова включваме Radiant, дърпаме в прозореца му същата папка и докато пуснеш бутона на мишката вече ги е заредил и подредил. А т.нар. скролване между изображенията е без никакъм забележим лаг. 3D реконструкциите също ги прави без да се замисля. В къщи го ползвам с wine и пак никакви грижи. Ако това са само мои впечатления, айде може да греша или да съм пристрастен, но всички колеги които познавам го ползват, освен казионните програми с които са принудени да работят.

[Naka]

А най-готиното от всичко е, когато трябва да се изчака нещо е да се прави  sleep() с празен цикъл. 
Любим подход при Жабарите, а и голямо изкушение.

_
Аз нещо да попитам, че ми стана интересно. Един томограф прави много ренгенови проекции. След от тези проекции математически се възтановява вътрешната 2д структурА.... Слайса или както там се нарича.... Кой го прави това томографско възтановяване... Самият апарат... Или програмата? Щото това е единственото дето се сещам за що годе повече изчисления.

От друга страна така както се представя програмата излиза, че това е един обикновен view-er на картинки в специализирани формати.
Не може един viewer на картинки да е бавен.

[4096bits]

А най-готиното от всичко е, когато трябва да се изчака нещо е да се прави  sleep() с празен цикъл. 
Любим подход при Жабарите, а и голямо изкушение.

_
Аз нещо да попитам, че ми стана интересно. Един томограф прави много ренгенови проекции. След от тези проекции математически се възтановява вътрешната 2д структурА.... Слайса или както там се нарича.... Кой го прави това томографско възтановяване... Самият апарат... Или програмата? Щото това е единственото дето се сещам за що годе повече изчисления.

От друга страна така както се представя програмата излиза, че това е един обикновен view-er на картинки в специализирани формати.
Не може един viewer на картинки да е бавен.

Какъв цикъл със sleep() след като може да му задаваш, колко време да чака. Ако някой го прави това, е най-голямата малоумщина

[vektorman]

Аз нещо да попитам, че ми стана интересно. Един томограф прави много ренгенови проекции. След от тези проекции математически се възтановява вътрешната 2д структурА.... Слайса или както там се нарича.... Кой го прави това томографско възтановяване... Самият апарат... Или програмата? Щото това е единственото дето се сещам за що годе повече изчисления.

От друга страна така както се представя програмата излиза, че това е един обикновен view-er на картинки в специализирани формати.
Не може един viewer на картинки да е бавен.

Самият компютър-томографски апарат реконструира първичните данни в 2D изображения, т.нар. слайсове. Самите слайсове са с предварително зададена дебелина от 0,6мм до 10мм, като дебелини от над 5мм отдавна не се използват. Минималната дебелина на слайса зависи от разделителната способност на апарата по оста Z. Тъй-като слайса има дебелина, то той не се състои от пиксели, а от воксели. Вокселите представляват кубчетата от които се състои слайса. Наричат се воксели (понеже имат обем V). Вокселът има цифрова стойност, означаваща усреднената стойност на плътността на скенираното вещество (в кубчето) по скала от -1000 до +3000. Тази скала се нарича Хънсфилдова скала, а мерните единици Хънсфилдови единици, съкратено на английски HU, на български ХЕ.  Стойност -1000ХЕ имат газовете, +3000 имат плътните кости, а водата има стойност 0. Слайсовете се записват от КТ-апарата в DICOM формат, като всеки слайс е на отделен файл. Всеки DICOM файл освен данните за изображението на вокселите, съдържа и информация за имената на пациента, номера на пациента, номера и датата на изследването, номера на серията от която е част изображението, както и още много информация подобна на EXIF информацията на обикновените цифрови снимки, само че много повече и по-подробна. Едно съвременно компютъртомографско изследване се състои от няколкостотин до няколко хиляди такива файла общо, разпределени в няколко серии.
В една папка на компютъра може да има няколко десетки хиляди файла, принадлежащи на различни пациенти, както и на едни и същи пациенти от различни дати. Работата на вюъра, когато му метнеш папката в прозореца, е първо да изгради дървовидна стуктура, като ги сортира по пациенти, после по изследвания подредени по дати и вътре в изследванията по серии, като ти изкара и иконки представляващи извадки от изображенията за всяка серия. После ако да речем искаш да сравниш две серии от изображения, примерно скенирания на бял дроб на един и същ пациент от различни дати, за да разбереш динамиката на заболяването му, трябва да разделиш на две прозореца на вюъра за всяка серия, като вюъра трябва да синхронизира слайсовете според сходствата им така, че във всеки прозорец слайсовете да са от едни и същи анатомични структури и когато прелистваш едната серия в единия прозорец, другата серия да се прелиства и тя във същата посока така, че да продължава съответствието и това ако може да става със скоростта с която мога да въртя колелото на мишката . Повечето лагят много, а което е най-лошото докато прелистваш едната серия в едната посока, другата се прелиства в обратната посока или забива. Освен това, тябва да има бързи клавиши за най-често използваните функции, които да са удобни и интуитивни. Трябва да има и възможност за мултипланарни реконструкции с промяна на наклона на равнините, което също много го нямат или се плаща отделно, като струва майка си и баща си, защото е претрупано за красота с много излишни неща, дето никой не би ползвал. Тези дето са написани на Java или на HTML ги знам, те си личат отдалеч и не искам въобще да ги коментирам. Тия дето са на C и C++ като скорост биват. Сред последните най-бързия и малък, пък със всичко необходимо, който съм виждал е въпросния RadiAnt. Аз дълго време не исках въобще да го знам, понеже като линукс-фундаменталист, все търсех достойна нативна линукс алтернатива. Като не намерих, започнах да го ползвам по съвет на колегите ми, които са пробвали пък всичко на уиндоус и не са намерили нищо по-добро.
Ето нагледно видео как се инсталира и работи под wine в убунту: https://www.youtube.com/watch?v=YiUgMQ-D3Vk Показано е и това със синхронизацията на сериите.

[Naka]

'Сърби' ме клавиатурата да се отплесна малко офтопик. Ама по-добре да го напиша, че и на мен ми е интересно.
В една друга тема се поставяше въпроса как е възможно да знаем структурата на земята, (като не сме копали толкова надълбоко), какво има вътре и как е разположено. Ами може като се използват същите принципи като в медицинската томография.

Значи томографа прави много ренгенови снимки под различни ъгли. От една страна е ренгеновата тръба, а от другата са ренгеновите детектори (които снимат). И цялото това нещо се върти и прави много ренгенови снимки/проекции под различни ъгли. Една единична снимка нищо няма да покаже, ще покаже нещо размазано. Но като се комбинират всичките и колкото повече такива снимки има (под различни ъгли), толкова по-добре и точно (математически) може да се възтанови от множеството снимки вътрешния (2д или 3д) изглед на обекта.
https://en.wikipedia.org/wiki/Tomographic_reconstruction

По подобие казват, че може да се възтанови вътрешния изглед на земята. Тук вместо ренгеновия източник играят ролята земетресенията, а вместо ренгеновите детекторите - сеизмичните детектори. Колкото повече сеизмични станции има разположени, на различни места толкова толкова повече проекции ще има. Даже си мисля, че понеже земетресенията се случват на различни места, това също дава различни проекции.

Накрая в линка на  lunarvalley https://rwu.pressbooks.pub/webboceanography/chapter/3-3-determining-the-structure-of-earth/ се говори за сеизмична томография.

Using data from many seismometers and hundreds of earthquakes, it is possible to create a two- or three-dimensional image of the seismic properties of part of the mantle. This technique is known as seismic tomography, and an example of the result is shown in Figure 3.3.6.

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

[vektorman]

Математическата теория която стои зад компютърната томография е още от 1917г и се нарича: "Реконструиране–възстановяване на структурата на двумерен обект (аксиално сечение от тримерен обект) по съвкупност от негови проекции". http://www.bsctr.bg/media/documents/presentations/Methods-for-visualization.pdf  Едва след 1970г, след достатъчното развитие на компютрите е станало възможно конструирането на първия КТ-апарат. Същата математика може да се използва не само в медицината.

[Naka]

Дай да го сметнем колко памет може да заема цялото 3д изображение от всички слайсове.
Мисълта ми е, че ако може да се кешира/зареди цялото 3д изображение в паметта, т.е това е по възможностите на един среден компютър, тогава лесно и бързо може да се прелиства, да се изваждат образи в различни равнини (под наклон) и т.н.
Дет вика Джета, няма да има отваряне и четене на файлове в цикъл. Един път изчетено, изчислено и заредено в паметта и от там по-лесно.
 
Каква е резолюцията на един слайс във воксели?

Казваш, че скалата е  от -1000 до +3000. Това е целочислено число и се събира в 12бита. 2¹²=4096.
Един воксел може да се събере в 1.5 байта (ако се пакетира) или в 2 байта (по мързелашката).

Например ако са 1000 слайса.
X*Y*1.5*1000 = ?

Много зависи с каква резолюция са единичните слайсове и броя на слайсовете.

[vektorman]

Стандартно изображенията са 512х512 пиксела https://www.gehealthcare.com/-/jssmedia/cbe584e1152c457391981cdf44fe88f6.pdf?la=en-us . При най най-новите и най-скъпи скенери https://www.siemens-healthineers.com/computed-tomography/news/mso-precision-matrix.html е избираема освен стандартната матрица, също и 768х768, 1024х1024, до 4096х1024 . Аз мисля че не съм виждал нещо повече от 512х512 досега.

[Naka]

О това въобще не са големи резолюции.
Нямат никакво оправдание да са лагави.

Значи.
512 х 512 х 1.5 х 1000 ≈ 393Mb
512 х 512 х 2    х 1000 ≈ 524Mb

Най-тежкия случай
1024 х 1024 х 2    х 1000 ≈ 2Gb

Спокойно може всичко да го зареди в паметта, или да го кешира като един голям 3д файл...
Един 2 Gb файл ssd дисковете го четат за 2-3 секунди. Не че едната програмка е пъргава.... По-скоро е нормална и правилно писана, а другата е сбъркана и лагава.

За асемблера съм съгласен с Ремо, че в днешно време може да е недостатък. Сегашните процесори със 'стотиците' им там sse  регистри ако им се даде да смелят нещо с плаваща запетайка, ще го смелят за 'милисекунди',  даже няма и да се замислят.
Едно време като студент се бях научил да пиша ин лайн асемблер в паскал. Пишеш пишеш и някъде в средата на някой проблемен цикъл слагаш асемблер. Получаваха се много хубави резултати.
Мисълта ми е, че един програмист много добре знае къде са тесните места в кода и може е да ги оптимизира или избегне.... (Ако няма кой да му стои на главата )

При един правилен код на С и компилатора ще свърши идеална работа със SSE регистрите.