On Sun, 14 Nov 2010 18:27:42 +0100, Grzegorz Krukowski
<r...@o...pl> wrote:

>On Sun, 14 Nov 2010 10:29:51 -0600, A.L. <l...@a...com> wrote:
>
>A.L, przepraszam że się wbijam kompletnie bez związku. Możesz polecić
>jakąś stronę, gdzie były by informacje historyczne na temat imigracji
>do USA? Szczególnie koniec XIX i początek XX wieku, z rozbiciem na
>kraje pochodzenia. Wasz odpowiednik urzędu statystycznego coś takiego
>udostępnia może?

Uszad Statystyczny to US Census. Jest od cholery materialow, na
przyklad ten

http://www.census.gov/population/www/documentation/t
wps0029/twps0029.html

"Historical Census Statistics on the Foreign-born Population of the
United States: 1850-1990"
Campbell J. Gibson and Emily Lennon

A.L.

do góry

On 14 Lis, 16:43, "Remek" <d...@g...com> wrote:
> Użytkownik "Mariusz Marszałkowski" napisał:
>
> Czasami w jakimś programie jakaś procedurę chciałbym napisać w
> asemblerze zamiast w C++ i uzyskać szybszy kod niż wygenerowany
> przez kompilator. Jakie platformy? Te najbardziej wydajne procesory
> AMD i Intela.
>
> ===========================
>
> Obecnie uzyskanie szybszego programu przez napisanie go w asm to w 99% mit.
Jaki algorytm jest w stanie wygenerować tak dobry kod maszynowy, że
uzyskanie
szybszego w 99% jest niemożliwe?

Pozdrawiam

do góry

Użytkownik "Mariusz Marszałkowski" <m...@g...com> napisał w wiadomości
news:97e61e3d-7242-4c8c-afca-5dc5e1539397@x4g2000pre
.googlegroups.com...
> Jaki algorytm jest w stanie wygenerować tak dobry kod maszynowy, że
> uzyskanie
> szybszego w 99% jest niemożliwe?

Języki wysokiego poziomu nie mają niektórych instrukcji jak obrót (rol,ror)
Poza tym specyficznych instrukcji procesora jak rdtsc

do góry

On 15 Lis, 00:41, "prorok" <p...@t...nie.adres> wrote:
> Użytkownik "Mariusz Marszałkowski" <m...@g...com> napisał w
wiadomościnews:97e61e3d-7242-4c8c-afca-5dc5e1539397@
x4g2000pre.googlegroups.com...
>
> > Jaki algorytm jest w stanie wygenerować tak dobry kod maszynowy, że
> > uzyskanie
> > szybszego w 99% jest niemożliwe?
>
> Języki wysokiego poziomu nie mają niektórych instrukcji jak obrót (rol,ror)
> Poza tym specyficznych instrukcji procesora jak rdtsc
Pojedyncze instrukcje nie stanową problemu, jwp mogą mieć funkcje do
tego celu.
Pozdrawiam

do góry

Użytkownik "Mariusz Marszałkowski" <m...@g...com> napisał w wiadomości
news:e4c6ad3c-c03c-4765-ac87-868d78c63a6a@n10g2000pr
j.googlegroups.com...
> Pojedyncze instrukcje nie stanową problemu, jwp mogą mieć funkcje do
> tego celu.


Dwojakie obejście - wywołanie procedury assemblerowej lub opisanie to inną
funkcją: dla obrotów ror,rol które muszą być szybkie bo mogą występować w
funkcji haszującej lub kryptografii - zamiast obrotu można użyć or z
przesuniętą zawartością (chociaż przydałaby się instrukcja obrotu w językach
wysokiego poziomu?)
Rdtsc zamknięte w procedurze (zwłaszcza takiej jak JNI Javy) jak również
wyspecjalizowane szukanie bitu (bsf,bsr) traci dużo na czasie wykonania. Ale
to wszystko gdy mamy przynajmniej WOŁANIE procedur assemblerowych. Jeśli
nie, to do szukania bituy trzeba by napisać własny algorytm a gorzej z
pomiarem czasu bo zostaje QueryPerformanceCounter też szybki ale rzędy
wielkości mniej dokładny niż rdtsc i jego wywołanie trwa trochę co może
przeszkadzać gdy chcielibyśmy zrobić bardzo dokładne profilowanie - pamiar
czasu wykonania określonych linii w funkcji.

Pozdrawiam

do góry

On Nov 15, 12:41 am, "prorok" <p...@t...nie.adres> wrote:

> Języki wysokiego poziomu nie mają niektórych instrukcji jak obrót (rol,ror)

int rol(unsigned x, int y) {
return (x << y) | (x >> (32 - y));
}

GCC kompiluje to do rol.

do góry

On 15 Lis, 06:21, "prorok" <p...@t...nie.adres> wrote:

> Rdtsc zamknięte w procedurze (zwłaszcza takiej jak JNI Javy) jak również
> wyspecjalizowane szukanie bitu (bsf,bsr) traci dużo na czasie wykonania.
Ostatnio sprawdzałem na C++, wygląda na to że dzisiejsze kompilatory
bardzo dobrze sobie z tym radzą, program przyspieszył o spodziewane
20%, kompilator nie dodał żadnego narzutu na wywołanie funkcji. Ale
fakt,
kiedyś tak nie było, w przeszłości często odnosiłem wrażenie, że po
dodaniu
jakiejkolwiek wstawki asemblerowej kompilator w ogóle nie umiał
zoptymalizować pozostałego kodu i wszystko działało wolniej niż
bez asemblera.

> to wszystko gdy mamy przynajmniej WOŁANIE procedur assemblerowych. Jeśli
> nie, to do szukania bituy trzeba by napisać własny algorytm a gorzej z
> pomiarem czasu bo zostaje QueryPerformanceCounter też szybki ale rzędy
> wielkości mniej dokładny niż rdtsc i jego wywołanie trwa trochę co może
> przeszkadzać gdy chcielibyśmy zrobić bardzo dokładne profilowanie - pamiar
> czasu wykonania określonych linii w funkcji.
Zawsze mierzę wiele razy w pętli i podaję najkrótszy czas.

> Pozdrawiam
Również

do góry