Изпечатай

[Odido]

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

[gat3way]

Няма никакви проблеми. Ако имам достатъчно време, мисля, че за месец-два, app-а ще е готов и ще го пусна в Google Play безплатно (е с рекламни банери най-вероятно). Така всеки ще може да си прави такива проучвания и статистики. Ако не ми писне и ако случайно спечеля реклама повече, отколкото за една бира дневно, ще подкарам и някакъв web service, който да събира и сервира такива неща. Ама най-вероятно няма да се стигне дотам.

Иначе интересни корелации има, но е дълга тема за разговор

[RealEnder]

@gat3way: това, което правиш подозирам, че отива към wigle.net
Android клиента им е с отворен код и работи доста стабилно. Кода: https://github.com/wiglenet/wigle-wifi-wardriving
Аз отдавна се каня да окастря wigle-а и да го интегрирам с http://wpa-sec.stanev.org . Добавяш си ключа вътре, пресканираш и до имената на мрежите да се появява има ли ги във wpa-sec-а, а ако ти си ги подавал, бонус - PSK-то

[gat3way]

Мхм, доста сходно като идея.

[gat3way]

Хах, тази вечер имах повече време да си играя и най-накрая си реализирах кеширането на резултати (беше доста досадно да се изчитат от базата всички рутери и да се пречертават при всяка смяна на координатите на камерата на картата).

Но по-забавното е че направих статистиките контекстно-зависими, демек вече мога да си правя статистика на базата на текущия "изглед" на картата, следователно грубо казано мога да си вадя статистики по квартали, при правилния zoom. Резултатите ме хвърлят в размисъл. Засега малката част от Младост 1, която съм мапнал, бие всички рекорди по несигурност, WEP се ползва повече от WPA2, WPS се ползва почти на 50%. Както беше споменато, има разлики в разбивката по производители. Хм, имам странното чувство че процента рутери на TP-LINK са в корелация с цената на имотите в квартала. И да, процента на Cisco е винаги висок в бизнес-райони (центъра и бул.България), докато примерно в Редута или Младост въобще не влиза в първите 10, което е логично.

Апропо, единия от screenshot-овете дето постнах е грешен, този с каналите, имаше off-by-one бъг и всъщност 11 и 6 са най-използвани (на мен тогава ми направи впечатление, ама реших че е заради малката статистическа извадка).

[anrydisappear]

оргинално публикувано от ApucTokpaT
TP-link са най-уязвими от към wps атаки -не създават никакви проблеми.В последно време обаче се напълни с мрежи на m-tel ,с които имам 0 % успеваемост интересува ме някой дали може да даде качествен линк с хардуера ,който използват ,благодаря предварително!

Здравей човек и мерси за инфото,моят рутер е TP-link но е доста стар,и не поддържа wireless security setup(wps),а относно m-tel мрежа досега не съм срещал да пробвам да разбия.

Gat3way,наскоро се закрастих отново да експериментирам относно сигурноста на протоколите(http,https,hsts)макар основният е http.След няколко опита с mozilla version 20.0.1(под proxy),успях без проблеми да си презапиша mail accounts от е-bay,paypal,hotmail,yahoo,bet365 като стартирам атаката чрез телефона и атакувам лаптопа си(докопах 1 msi) на порт 443(https)но gmail и twitter упорито отказват,директно ме прехвърлят на https,впрочем за twitter се показва надписа "warning try to redirect to http://www.twitter.com"но след като дам съгласието си,така и  не може да се справи да прехвърли на http,макар че основната роля на sslstrip e точно това,да задържи протокола какъвто и е подаден чрез команда(дано да не бъркам).Странното е че след като изтрия mozilla и после пак я инсталирам 1 опит е успешен,независимо от кой сайт искам да взема някакви данни.После като порових открих тези 2 мнения за gmail и twitter

"Both use HSTS headers now, so if you're using a browser that supports them (like Chrome,or firefox),there's no opportunity for sslstrip to do anything. That output is from Twisted,and it doesn't indicate any actual problem."

и 2-то:

"HSTS fixes this problem by informing the browser that connections to the site should always use SSL. Of course, the HSTS header can be stripped by the attacker if this is the user's first visit.Chrome attempts to limit this problem by including a hard-coded list of HSTS sites.Unfortunately this solution cannot scale to include all websites on the internet; a more workable solution can be achieved by including HSTS data inside DNS records, and accessing them securely via DNSSEC."

Накрая намерих това  https://www.owasp.org/index.php/HTTP_Strict_Transport_Security

Ти имаш някакви наблюдения основно за mozilla говоря,а и да те попитам нещо друго,не знам дали това не е в сферата на фантастиките но,ако имаше някакъв софт който само чрез да cap file извлечен чрез handshake да може да вириуализира паролата щеше да бъде невероятно,един вид да се обезмисли използването на речник

note:ако искаш прехвърли темата някъде другаде тъй-като тука говорим за протоколи а пак все заглавието на темата е  за reaver

[gat3way]

Ами не знам дали sslstrip може да премахва HSTS хедърите, но дори да го прави, това ще сработи само ако за пръв път отваряш сайта. Ако искаш все пак да се опиташ да mitm-ваш SSL връзки, можеш да пробваш да DNAT-ваш трафика към някое зло прокси, от сорта на това: http://crypto.stanford.edu/ssl-mitm/

Естествено, ще предоставяш самоподписани сертификати, браузърите ще реват, по-умните потребители няма да отварят twitter със самоподписан сертификат и т.н.

Тук има един такъв момент, че ако можеш да подписваш сертификати от името на trusted authority, измамата става пълна и съответно можеш да следиш трафика в чист вид в реално време, както и да го манипулираш. Това вече се е случвало примерно с едно CA с порочни практики, което продаваше на клиентите си - компании средства да слухтят служителите си, съответно повечето браузъри разкараха root CA сертификатите му от доверените си списъци. Същият ефект би имало ако компрометираш някое authority. Разбира се, вероятността това да се случи е доста ниска.

Специално за mozilla и HSTS хедърите нищо не мога да кажа.

Няма такъв софтуер, който от cap файл ей така магически да ти визуализира preshared key-а. Към момента най-доброто на което може да се надяваш е да се възползваш от специализиран хардуер за паралелна обработка (GPU или FPGA) - примерно скорост от около 1 милион опита/секунда може да се докара със система с 7 AMD Radeon HD7970-ци, на цена грубо около 10 хиляди лева. При тази скорост можеш да си позволиш доста по-сложни занимания от това просто да му засилиш речници - примерно можеш да комбинираш речници, да прилагаш разни трансформации и т.н.

Предвид че може да се каже че имам идея каква е криптографията в WPA-PSK, не мисля че в близко бъдеще ще има някакъв пробив в това отношение, извън това че хардуера става по-бърз с времето.

[gat3way]

Да споделя занимавките ми с андроид-ската простотия, доста напреднах

На първо време за всеки access point по картата вече може да се изкарва доста детайлна информация - освен обичайните SSID/BSSID/Manufacturer/Channel, както и security настройките, вкарах нещо забавно. По принцип честотната лента е разделена на 14 канала, но тези канали се "презастъпват". На който не е чувал за това, нещата изглеждат така:



Сега ако се базираме на факта, че силата на сигнала намалява пропорционално на разстоянието на квадрат, както и на въпросната графика, то ние можем да сметнем ако един AP работи на някакъв канал, доколко околните AP-та му "пречат". Та в момента показвам колко е "замърсен" ефира с един recommendation да сменим канала на най-малко задръстения такъв. Получи се забавно.

Другите неща: имаме статистика и за най-използваните SSID-ове (във вид на pie chart, гадно е и е дълго да обяснявам защо реших така). Имаме филтър на база SSID (като филтъра може да игнорира lower/uppercase и да работи като "exact match" или "contains".

Вкарах нещо, наречено "security score", което определям по моя си формула. Съжалявам, но не намерих някаква меродавна формула за нещо подобно.

Допълнително съм "сканирал" около 1/4 от центъра на София плюс 2 от моловете (последното е забавно).

Wigle.NET се оказаха големи педерасти: събират информация за encryption-a на връзката, но тя идва като един низ, който те нямат никакво желание да парсват при клиента, нямат желание и да експортват такава информация в API-то си, за теб има само "отворен" и "затворен" hotspot. Това е доста дразнещо и няма как да постигна съвместимост с тяхната база. Въпреки това, този факт не им пречи да генерират статистики на база encryption, които са достъпни през уеб сайта им. Грррррр.


Какво ми остава:

* Търсене на AP по SSID от главното activity.
* Избирателно стартиране на service, който да слухти и да пълни базата, докато приложението не работи.
* По-финни настройки от сорта на "ако се движим с по-висока скорост, сканирай по-начесто" или "ако батерията е почти изтощена, изключи се" (wigle.net го прави и мисля че е добра идея).
* Статистиките да отразяват филтрите избрани от потребителя, не само текущият изглед.
* Експорт на данните в KML/CSV формат.
* Обмяна на базите през NFC/Bluetooth

Когато свърша с тези неща, ще го пусна безплатно в Google Play. Мисля обаче този път да подходя по-меркантилно към нещата (а и защото ми е интересно) и да сложа реклами в приложението. Тук нямам никаква идея, след известно четене и предишен опит, стигнах до извода, че от банери файда няма - мен поне ме дразнят ужасно много. Та идеята ми е да сложа една interstitial реклама на цял екран при затваряне на приложението. Не знам дали е добра идея. Някой дето се занимава с такива неща (n00b?) ще съм радостен ако налее акъл по въпроса. Засега съм се спрял на LeadBolt, Admob май не предлагат такива екстри за обикновени педерасти.

Иначе забавни наблюдения: не знаех че Vivacom имат толкова голяма мрежа от wifi access point-ове. Само в центъра на София са десетки, но имат доста и по кварталите.

[anrydisappear]

Здравей Gat3way,sorry че не съм писъл отдавна но нали знаеш като си купиш на старо някоя машина проблемите изкачат един след друг,нещо подобно както Дянков и валутният резерв.
Относно твоето приложение,наистина доста е различно от другите,защото в маркета поне аз подобно не видях(на моята н900,имам 2 OS droid 2.3.4)въпроса е доколко хората се интересуват от инфо относно безжичните връзки които ги заобикалят.

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

Чудя се защо не си вземеш една нокиа н900,безтуй забелязвам че стихията ти е security testing,а този тел.(по точно таблет)има какво да ти предложи, а и има серизона подкрепа от linux ентусиасти,които да ти кажа много добре сърфират през безбрежният океан от linux world,но в крайна сметка ти имаш крайната дума.

Не знам доколко човек може да печели от development applications,защото аз не разпологам с такъв умствен капацитет,но имам 1 приятел който се занимава с правене на сайтове по поръчка(мисля че работи на php)той ми сподели че наистина не се лишава от нищо,а неговата душа граби с пълни шепи от живота.

Относно рекламата,ако наистина приложението ти добие някаква популярност(дано да се получи)те сами ще те потърсят.

В последно време,споря с 1 луд фен на тема хардуер(тука съм като индианец в макдоналдс)и софтуер,за това колко са физични и виртуални ядра в процесорите.Преди време бях срещнал едо мнение относно точно тези метафорични явления.

Та този експерт споделя че всъщност 4 ядрен процесор(говоря за мобилни такива)не са 4 ядра,а само 2,но в самият чип има повече нишки(тука вече забравих точното определение)и когато софта праща заявки за повече ресурси,тези нишки разделят ядрата на 2-реални+още 2 виртуални,специално ставаше дума за samsung galaxy s3 и samsung galaxy s4 и въобще за чипове в мобилни телефони

Знам че андроид ядрото е основано на linux kernel,(не е зле Torvalds да си поиска,обезщтетение от всички компании които го използват+iphone,тъй-като те ползват част от кода му)и тука идва забвната част.

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

Ти човек,а и останалите в този форум сте доста навътре относно linux kernels,въобще логически като се замислиш вярно ли това(става дума за физичните и виртуалните ядра и дали в кернела е зададено по подразбиране за тези нишки)или този фен се е оказa прав че няма нищо вярно в тази теория.
Ще се радвам много,да чуя ваште мнения

[remotex]

Накратко моите 5 ст. по въпросите за хардуера и софтуера..

Като софтуерен специалист най-напред ще п/оставя отворен въпроса за това - микрокода в един процесор софтуер ли е или хардуер? - нека хардуерните специалисти отговорят
който инак освен от БИОС може да се управлява/оправя и от ядрото чрез microcode_ctl

За виртуалните и реалните ядра/нишки - те всички са реални (изключвам мноого старите компютри, отпреди 10 г. дето не се намират вече, където  многозадачността бе изцяло софтуерна - просто много бързо превключваха между задачите и създава впечатление за едновременно изпълнение)

Напр. програмката  CPU-Z много добре показва (на най-долния ред: Selection, Cores, Threads - Total):
в моя случай: 2 - ядра, 4 - нишки, а на работа имаме едни чудовища Xeon 8 - ядра, 8 - нишки
и ядрата и нишките са си реални хардуерни обаче по-добре е когато бр. ядра е равен на бр. нишки 
тогава нямаме състезаване между 2 и повече нишки за един и същи ресурс
т.е. напр. машина с 4 ядра и 4 нишки е по-бърза от такава с 2 ядра и 4 нишки - и двете ОС ще ти ги показва като 4 процесорна машина
но не много по-бърза, не е 2 пъти напр. ами около 15%
Проблемът идва оттам, че ако двете нишки които са на едно ядро поискат един и същ ресурс едната ще трябва да изчака - напр. и двете искат да събират целочислено, тук паралелизма идва когато едната иска да прави нещо друго напр. събира числа с плаваща запетая (има си отделен конвейер за това), достъп до паметта или кеша и пр. всичко което не е в конфликт с това което иска да ползва другата т.е. те не са виртуални нишките, а са си хардуерни ..хардуерните спецове май им викат конвейер(и) в процесорното ядро.

Ако искаш да тестваш пусни един биткоин миньор (аз поне с това тествам).
При мен напр. на 4 = 2 х 2 машината
с 1 ядро постига 1.0 - 1.2 МХ
с 2 и 3 ядра дига 2.0 до 2.2 МХ - тук е линейно ускорението
с 4 ядра дига едвам 2.4 МХеша/сек - тук вече не е линейно щото те всичките 4 нишки искат да ползват целочисления конвейер ама той вече е зает от другата нишка, докато на 4 = 4 х 1 очаквам линейно да скочи от 2.0 на 4.0 МХ (ама шефа не дава да пускам на сървърите 8 = 8 х 1 та да разбера  )

А у дома напр. моят е 6 ядрен Феном 2 - ама прави една гадост като се усети че е много натоврен си ги сдвоява "хардуерно" т.е. вместо 6 има 3 ядра които работят малко по-бързо т.е. нали се сещаш от примера по-горе дето вади с 15% плюс, че всъщност другата нишка на същото ядро за да вдигне толкоз малко ще забави работата на първата с доста...
"хардуерно" е в кавички щото според мен микрокода може да мине за хардуер

За това ако може купувайте си процесори в които бр. ядра = бр. нишки (конвейери или както още им викат там)

П.П. Примера е с битпара щото очаквам и "вейката" да се включи 
П.П.П. "вейката" е "гад3вей"-ката 

Може троловете вече да налазват по темата

// Малка редакция - всичко по-горе е за настолни машини! При мобилните има една подробност - там гадовете броят и комуникационния процесор - та той доскоро беше един процесор и се ползваше за управление на антената и за изчисления та имаше някои двуядрени които обаче като извадиш -1 комуникационен процесор пак си оставаш само с един за работа т.е. той комуникационния за друго не се ползва - отделен чип си е за упраление на антената (приемане, предаване, де/кодиране и т.н.)
А някои имат и: Not previously disclosed publicly, vSMP includes a fifth CPU core (the “Companion” core) built using a special low power silicon process that executes tasks at low frequency for active standby mode, music playback, and even video playback.

[gat3way]

anrydisappear, иначе "изолиране" няма, просто някакви сметки се правят на база разстоянието между точките и канала на който излъчват. Тъй като GPS-а е доста неточен обаче (в някои случаи може да даде дори десетки метри отклонение), съответно и сметките не са идеални. Тук има два варианта - правиш сметките на място и на база сила на сигнала, това е доста по-точно, но не го правя. Или се възползваш от това че вече си мапнал точките и им знаеш параметрите - това е по-неточно, но пък работи за който и да е AP, който си мапнал, без да се налага да си в обхвата му.

Нокия няма да си взема, па макар и с нормален линукс отгоре. Също така и нямам намерение да се изхранвам с писане на мобилни приложения, имам си друга, съвсем различна работа и това е по-скоро отскорошно хоби. Тъй като нямам много идея от нещата ми е интересно. Специално нещата с рекламите още повече. Не ме интересува печалбата и не мисля че ще е особено голяма, но има друг момент. Има няколко вида реклама - примерно банери, цял екран, appwall, notification реклами и т.н. Според мен е много забавен момента кой точно вариант е най-подходящ, къде и как трябва да се позиционира така че хем да има някаква финансова файда от една страна, хем да не дразни потребителите от друга, хем да не омазва потребителския интерфейс и да не те разсейва от трета. Другото интересно е че очевидно има десетки рекламни мрежи, които имат различен модел на плащане и съответно различни печалби и всичко зависи точно как си направиш нещата. Момента с рекламата ми е почти толкова интересен, колкото момента с писането на приложението. Отначало си мислех че това е простотия и просто пльоскаш няколко реда код някъде, онова показва някаква реклама от време на време и това е, но всъщност нещата били доста по-сложни и забавни.

Андроидското ядро е линукско ядро с някакви пачове отгоре. Ако се абстрахираме от dalvik простотиите и гугълските API-та, отдолу си има един обикновен линукс - със съвсем обикновен шел (busybox) и стандартния набор системни приложения.

Самсунга мисля беше с 4-ядрен cortex-a9. Доколкото знам 4-те му ядра са си истински 4 ядра, т.е не са някаква измишльотина от рода на 2 ядра с hyperthreading или пък на AMD тъпотията с булдозерите дето уж са отделни ядра, ама си споделят L1 кешове, SIMD ALU unit-и и тем подобни неща.


Говори се че новия им таблет ще е с 8-ядрен A15/А7, там с тези big.little тъпни. big.little е ARM-ска чудесия, където примерно половината ти ядра са по-мощни и харчат повече ток, другата половина са по-слабички и по-икономични. Идеята е да се пести ток като само CPU-интензивните процеси се schedule-ват върху мощните ядра, останалите работят на по-слабите и съответно се харчи по-малко ток. За целта обаче трябва да има добра подръжка в ядрото (най-малкото task scheduler-а трябва да е "aware" за тези неща), специално в линукс това е доста отскоро и не са толкова зрели нещата.

[gat3way]

remotex, всичко идва оттам, че в линукс 2.6 и нагоре task-а е атомарната единица на scheduler-а. Под "task" се има предвид софтуерна нишка, всяка нишка си има отделен tid, разбира се в рамките на един процес нишките споделят общо адресно пространство, но имат отделни стекове. В 2.4 не беше така, там процесът беше атомарната единица и "софтуерните" нишки се schedule-ваха не от ядрото, а от userspace библиотека.

Scheduler-а може да изпълни един task върху един логически процесор (ядро) в един момент от времето. Поради това най-логичното и нормалното е че за CPU-интензивни приложения, оптималният вариант е да се spawn-нат точно толкова нишки, колкото е броя на ядрата. Ако създадеш по-малко нишки, няма да утилизираш процесорните ядра като хората. Ако създадеш повече нишки, няма да спечелиш - понеже task scheduler-а няма как да ги schedule-не на повече логически процесора, отколкото имаш. Дори най-вероятно ще загубиш заради overhead-а от context switch-ването.

Hyperthreading-а е нагоден малко грубо в цялата картинка и изглежда почти като отделен логически процесор от софтуерна гледна точка, с една такава уговорка че единствено task-ове, които споделят едно и също адресно пространство могат да се schedule-ват едновременно върху двете "хардуерни нишки".

Причината е че hyperthreading-а е една малка хитрост. На практика това не са две отделни ядра, а просто два набора от регистри плюс някаква железария за превключване между тях. Идеята е следната: когато една програма заяви някаква памет, имаме два проблема: латентност и bandwidth. Латентността е голям проблем, особено ако заявените данни не са в кеш паметта, а във RAM-а, за времето за което ще се изчете оттам един cacheline (32 или 64 байта), процесорът би изпълнил поне няколкостотин инструкции, но няма как да го направи, защото е block-нат, чакайки memory controller-а да му достави данните. Та hyperthreading-а прави един фокус: ако се стигне до такова положение, вместо да хаби процесорно време, веднага превключва набора от регистри (включай instruction pointer регистъра) и така на практика превключва към другата задача. За да работи това обаче двете задачи трябва да имат общо адресно пространство, в противен случай трябва да се изчисти TLB кеша и това отнема доста тактове и обезсмисля задачата.


Bitcoin е идеален пример за CPU-интензивно приложение. При него всичко това важи с пълна сила. Предполагам има файда да го пуснеш с точно толкова нишки, колкото физически ядра има процесора, като въпреки наличието на hyperthreading-а, файдата от пускането на повече нишки е минимална до отрицателна.

[remotex]

gat3way поправи ме ако греша, но нас навремето ни учеха че...
напр. едно ядро с две нишки може да изпълни напълно паралелно едната нишка/конвейер целочислено събиране а другата събиране с плаваща запетая (и двете не са дълги операции подлежащи на изчакване та да се наложи превключване на контекста) т.е. не е баш като да е едното да чака другото и да са различни регистри с общ процесор, по-скоро са си два отделни конвейера - спират се само ако едния блокира даден ресурс (щото го ползва) напр. ако едната нишка е заела FPU то другата не може да го ползва или ако едната първа е заела ALU то другата ще чака т.е. само някой ресурси са икономисали - защо?
та какво му е толкова скъпото на 1 ALU че да пестят и да слагат само по едно - айде за FPU знам че е скъпо, ама тук един колега май вече сам си направи ALU верно 8 битово - очаквам и той да се включи по тази тема - зьз...

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

[gat3way]

Не мисля, поне hyperthreading-а на Intel доколкото знам не е точно така. Първо, няма два pipeline-а, има само един (обратното би използвало доста повече от площта на чипа и би излезнало скъпо). Не мисля, че има вариант при който едната "нишка" ползва FPU-то, докато другата прави целочислени операции. Доколкото знам, "презастъпването" става само когато при други обстоятелства бихме имали pipeline stall (примерно гореописания случай с четенето от паметта или пък грешно предсказан branch, където всичко от pipeline-а се discard-ва и новите инструкции се изчитат от паметта). Това в Bulldozer чиповете на AMD се вписва доста по-успешно, но там освен споделените ресурси имаме и "удвоени" такива, примерно integer ALU-тата са две копия на ядро. Ама мога и да греша за това. Това което със сигурност мога да твърдя е че няма как да schedule-неш два процеса с различни адресни пространства върху двете "хардуерни нишки" или и да го направиш, би било ужасно неефективно и ще обезсмисли цялата идея. Причината е че "мапването" на виртуална спрямо физическа памет става на базата на page таблици. Тези page таблици стоят в RAM-та и понеже често се достъпват, съответно влизат в кеша. Тъй като обаче двата процеса имат отделно адресно пространство, съответно различен мапинг, при "превключването" между тях, кеша трябва да се изпразни, в противен случай за двата процеса това което е на виртуален адрес X ще бъде съдържанието на физически адрес Y и ще настане голяма тарапана. Изчистването на кеша обаче е доста скъпа операция, защото последвал достъп до този виртуален адрес ще stall-не процесора за да се изиска първо съответния елемент от page таблицата от RAM-та (при изхвърлен кеш). Та да - на теория сигурно е възможно да се schedule-ват различни процеси. На практика, всяка операционна система би се стремяла да schedule-ва единствено нишки с общо адресно пространство, иначе не само че няма да се намаже от цялата работа, ами ще се прецакаме.

Това което помниш с ръчно-писания асемблер е поради друга причина (аз съм се сблъсквал с това с C код и SSE intrinsics, там има файда от "interlace"-ване на няколко операции върху отделен set от данни). Това няма общо с hyperthreading-а, има общо с утилизацията на pipeline-а. Изпълнението на една инструкция всъщност има доста етапи - образно казано fetch-ване от паметта, decode-ване на инструкцията, изпълнението й там където трябва да се изпълни, но истинските "етапи" са над 10. Pipelining-а "презастъпва" няколко инструкции стига да няма зависимости между тях така че да не чакаш примерно 15 такта докато свърши едната инструкция, после 15 за следващия, а да се стремиш паралелно да изпълниш колкото може повече инструкции, стига да няма конфликти. Тъй като FP и integer железариите са различни, определено уплътняваш по-добре конвейера, редувайки такива инструкции. Парадоксално, понеже конвейера е доста дълъг и някои от под-операциите стават на няколко стъпки, спокойно можеш да намажеш ако можеш примерно да изпълниш няколко сходни операции една след друга, но опериращи независимо върху различни данни. Примерно със SSE инструкциите върху повечето модерни процесори ако успееш да докараш 3 последователни SSE инструкции опериращи независимо върху различни данни, само заради по-добре уплътнения pipeline скоростта на изпълнение е горе-долу 2 пъти по-висока.

[remotex]

Така беше навремето - един процесор, една нишка...
Добре де като казваш че железарията е различна сега не може ли същата ситуация ама с две нишки на едно ядро - едната само sse другата само целочислено, от един процес са примерно - щом като железарията е различна и конвейерите са си изчели и кеширали данните - би трябвало да може да ги смята паралелно двата конвейера - SSE и целочислено ама аз им викам FPU/ALU?
Нали и днешните имат sse
Ей ама много гледат да икономисват в последно време, ей