On 2013-03-23 21:42, Bronek Kozicki wrote:
> On 22/03/2013 15:54, Marek Borowski wrote:
>> On 2013-03-21 23:09, M.M. wrote:
> ...
>>> No dobrze, ale skąd ta pewność? Czy jesteś pewny na 100% że nie
>>> da się napisać kompilatora który dla przeciętnych programów
>>> wygeneruje kod 2 razy szybszy?
>> Pewnie ze da sie, ale dopuki komitent standaryzacyjny bedzie sie
>> zajmowal abstrakcjami a nie wprowadzal do core jezyka nowych typow
>> danych ktore sie mapuja 1:1 na nowe sprzetowe rejestry to IMO nic sie
>
> a jak sobie wyobrażasz specyfikację języka który mapuje typy 1:1 na
> sprzętowe rejestry? I jak ma to pomóc w optymalizacji przeciętnych
> programów?
>
char, int, long -> mapuje sie w rejestry uniwersalne
float, double -> mapuje sie w rejestry koprocesora

Swiat idze do przodu, rejestry uniwersalne sie wydluzyly i pojawily sie
rejestry jednostek wektorowych, a w C/C++ juz niekoniecznie.


co za problem dodac uint8_vt, uint16_vt, uint32_vt i operacje na nich ?

uint8_vt = 0x03030303;
uint8_vt = 0x02020202;
uint8_vt = v1*v3; // 0x06060606

z vektorowym float byloby nieco trudniej ale cos mozna wykombinowac.


Co do drugiej czesci:

Wspolczesne CPU i tak za zbyt szybkie dla przecietnych programow, moga
wykorzystywac 1/10 funkcjonalnosci i bedzie dobrze. Pozatym przecietny
program po stronie klienta to niedlugo bedzie pisany wylacznie
javascripcie wiec prymitywne typy danych i tak nie beda mialy znaczenia.

Natomiast co do innych zastosowac to wystarczy spojrzec w kod np. VLC
(precyzujac bibliotek) Jakos tak sie dziwnie sklada ze najbardziej
krytyczne fragmenty np. transformata cosinusowa sa jednak pisnanie z
uzyciem niestandartowych rozszezen czy wrecz asemblerze. Jakby dalo sie
napisac czysty kod ktory kompilator by zoptymalizowal dostatecznie
dobrze na jednostke wektorowa to by chyba tam byl jedyny, nie uwazasz ?


Marek