Translation of http://youtu.be/3jg1AheF4n0 - O'Reilly OSCON Java 2011: Martin Odersky, "Working Hard to Keep It Simple"

subtitles.txt

00:00:02.800,00:00:05.320
Dziękuję za zaproszenie i możliwość
wystąpienia tutaj.

00:00:05.830,00:00:10.430
Właściwie mam dzisiaj dwa wystąpienia
później tego popołudnia,

00:00:10.850,00:00:14.960
ponieważ zastępuje również Jonasa
Bonera w wystąpieniu na temat Akka

00:00:15.170,00:00:17.910
więc moje wystąpienie będzie bardzo
skompresowane,

00:00:18.150,00:00:20.180
ponieważ w tym kontekście chcę was
wprowadzić do obu tych wystąpień.

00:00:20.600,00:00:24.130
Wyzwanie, przed którym stoimy i które
chcemy podjąć 

00:00:25.030,00:00:27.300
jest wyzwaniem, które każdy zna.

00:00:27.700,00:00:30.140
Wywodzi się ono z około wieku rozwoju
sprzętu.

00:00:30.640,00:00:33.560
Przez ostatnie około pięć lat prędkości
taktowania przestały rosnąć w

00:00:34.090,00:00:35.370
mikroprocesorach.

00:00:35.850,00:00:40.990
W zamian za to widoczny jest wzrost
liczby rdzeni w tym samym tępie jak

00:00:41.440,00:00:45.050
rosła prędkość taktowania w 2005.

00:00:45.270,00:00:49.150
I to, wcześniej czy później, zacznie
dotykać coraz więcej programistów.

00:00:49.580,00:00:51.570
Prawdą jest, że istnieją obecnie takie
"wyspy", które mówią:

00:00:51.960,00:00:55.090
"Nie dotyczy mnie zrównoleglenie, nie
dotyczy mnie konkurencyjność.

00:00:55.520,00:00:59.640
Mam tylko prostą aplikację, które ma
umieścić dane w tabeli na serwerze i na

00:00:59.870,00:01:01.080
ekranach"

00:01:01.090,00:01:03.170
I to jest w porządku.

00:01:03.410,00:01:05.850
Więc będą "wyspy", które będą w jakiś
sposób chronione,

00:01:06.170,00:01:09.200
ale "woda" się unosi, bo prawdą
fundamentalną jest, 

00:01:09.640,00:01:13.050
że procesory nie robią się już szybsze na
rdzeń, ale przybywa rdzeni,

00:01:13.390,00:01:15.380
więc musimy coś z tym zrobić.

00:01:15.780,00:01:21.380
Architekci sprzętu spostrzegli to już w
2004 roku i wymyślili termin PPP:

00:01:21.780,00:01:24.490
"Popular Parallel Programming"

00:01:24.820,00:01:27.630
 wielkie wyzwanie upowszechnionego
programowania zrównoleglonego

00:01:27.970,00:01:31.470
Wyzwanie polegało na tym, że "jeśli
zaprojektujemy ten sprzęt

00:01:31.780,00:01:34.650
nie będziemy wiedzieli jak ludzie będą
mogli tego używać.

00:01:35.030,00:01:38.180
Oni nawet nie prosili o ten rodzaj
sprzętu,

00:01:38.510,00:01:41.390
ale to jest jedyny rodzaj sprzętu, jaki
możemy w przyszłości konstruować

00:01:41.850,00:01:44.300
więc tak właśnie dostosujemy nasze
praktyki programistyczne."

00:01:44.630,00:01:46.780
Jedna rzecz jest tu bardzo ważna:

00:01:47.240,00:01:49.900
są tak na prawdę dwa trendy i są one
często łączone w jedno

00:01:50.330,00:01:54.040
ale uważam, że się znacznie różnią.

00:01:54.500,00:01:56.260
Jednym jest konkurencja, drugim -
zrównoleglenie.

00:01:56.690,00:01:58.810
Programowanie równoległe oznacza, że
chcemy użyć tych dodatkowych rdzeni i

00:01:59.280,00:02:01.460
procesorów, by wykonywać programy
szybciej.

00:02:02.060,00:02:04.840
Ale te programy mogą równie dobrze
działać sekwencyjnie.

00:02:05.230,00:02:08.210
Możemy tylko użyć dodatkowego sprzętu,
by wykonywać je szybciej.

00:02:08.540,00:02:12.620
Programowanie konkurencyjne dla
odmiany jest, gdy mówimy:

00:02:13.070,00:02:15.640
"Cóż..., mamy coś co jest
charakterystycznie konkurencyjne...

00:02:16.000,00:02:20.270
Coś takiego jak Twitter, gdzie setki
tysięcy, tysiące tweetów na sekundę,

00:02:20.710,00:02:23.520
setki tysięcy przeniesień i tym
podobnych. 

00:02:23.980,00:02:27.650
I wszystko to musi być obsłużone w
czasie rzeczywistym,

00:02:28.080,00:02:31.040
wieć musicie mieć charakterystycznie
konkurencyjną aplikację."

00:02:31.450,00:02:36.370
Te dwa trendy: konkurencyjność i
zrównoleglenie mają wiele cech

00:02:36.790,00:02:38.150
wspólnych

00:02:38.370,00:02:41.550
i jedną z nich jest to, że oba są teraz zbyt
trudne.

00:02:42.010,00:02:43.840
Są zbyt trudne, by zrobić je dobrze.

00:02:44.120,00:02:47.840
I ta trudność po części jest
fundamentalna i po części wtórna.

00:02:48.160,00:02:51.460
Więc najpierw pokaże wam, co uważam
za fundamentalną trudność,

00:02:51.680,00:02:57.560
a potem powiem wam co robimy w Scali,
by pozbyć się tej wtórnej złożoności.

00:02:57.990,00:03:03.530
Więc fundamentalnym problemem jest,
że w jakiejkolwiek aplikacji

00:03:03.970,00:03:07.980
konkurencyjnej

00:03:08.290,00:03:11.550
mamy nieokreśloność, która jest
spowodowana tym, że równoległe wątki

00:03:11.860,00:03:14.180
używają tego samego, zmiennego stanu.

00:03:14.680,00:03:16.650
Mamy tu bardzo prosty program.

00:03:17.140,00:03:19.480
Byliśmy celowo mało szczegółowi jeśli
chodzi o model współbieżności.

00:03:19.940,00:03:21.800
Mamy po prostu dwa asynchroniczne
obliczenia: 

00:03:22.290,00:03:25.900
jedno dodaje do zmiennej 'x' jeden,
drugie mnoży ją przez dwa.

00:03:26.390,00:03:28.790
Pytanie brzmi co ten program może
"dać"?

00:03:29.280,00:03:33.170
I zależnie od modelu wspóbieżności i
jaka jest faza księżyca albo jak ta rzecz

00:03:33.660,00:03:37.350
będzie wykonana wynikiem może być 0, 1
lub 2.

00:03:37.610,00:03:40.950
Więc to jest fundamentalny problem i to
wymaga robienia wielu zabawnych

00:03:41.360,00:03:42.450
rzeczy, 

00:03:42.710,00:03:46.480
jak heisenbugi, gdzie w momencie
dodania instrumentacji bug znika

00:03:46.840,00:03:48.870
bo twój czas wykonania jest inny.

00:03:49.160,00:03:52.660
Masz rzeczy, które zauważa twój klient, a
momencie odtwarzania na twoim

00:03:52.940,00:03:54.910
sprzęcie problem znika.

00:03:55.280,00:03:57.370
Zabawne rzeczy, które nie dają spać
programistom.

00:03:57.680,00:04:01.410
Tak więc podstawowym problemem jest
fakt, że nieokreśloność wynika z

00:04:01.630,00:04:03.620
równoległego przetwarzania i
zmiennialnego wspólnego stanu.

00:04:03.850,00:04:06.840
I goście od sprzętu mówią nam: "Cóż,
przetwarzanie równoległe jest faktem.

00:04:07.100,00:04:08.380
Musicie z tym żyć."

00:04:08.640,00:04:11.910
Więc jedynym sposobem powrotu do
zdrowia psychicznego jest pozbycie się

00:04:12.080,00:04:14.230
zmiennego stanu.

00:04:14.560,00:04:16.000
Albo zminimalizowanie go, próba
zredukowania go jak tylko się da.

00:04:16.490,00:04:21.890
I to wyjaśnia renesans programowania
funkcyjnego, które widzieliście w ciągu

00:04:22.130,00:04:23.270
ostatnich pięciu lat. 

00:04:23.540,00:04:26.890
Nagle progamowanie funkcyjne wraca na
światło dzienne i ludzie uważają że to

00:04:27.090,00:04:29.630
będzie bardzo ważna technologia
programowania.

00:04:29.840,00:04:32.960
To pochodzi z tego na prawdę bardzo
podstawowego równania.

00:04:33.370,00:04:36.020
OK. Innym sposobem wizualizacji tego
graficznie jest

00:04:36.340,00:04:39.560
gdy muślicie w kategoriach czasu i
przestrzeni.

00:04:40.050,00:04:44.420
Kto pisał tutaj programy funkcyjne?

00:04:45.500,00:04:46.970
OK!

00:04:47.470,00:04:49.610
Świetnie!

00:04:49.170,00:04:54.370
Skoro to robiłeś, to myślę że się ze mną
zgodzisz, że więszkość myślenia,

00:04:54.610,00:04:56.930
podejścia do programowania funkcyjnego 

00:04:57.120,00:04:59.100
jest całkiem inny od podejścia
imperatywnego.

00:04:59.480,00:05:01.620
Imperatywnie myślimy o czasie.

00:05:01.950,00:05:04.690
Komputer wykonuje najpierw to, potem
tamto...

00:05:04.860,00:05:09.030
I muszę być ostrożny żeby zainicjować tę
zmienną przed jej użyciem.

00:05:09.370,00:05:11.750
To jest bardzo "czasowe" myślenie.

00:05:12.140,00:05:14.520
W programowaniu funkcyjnym się tego
nie robi.

00:05:14.730,00:05:16.200
Myślisz w kategoriach przestrzeni.

00:05:16.620,00:05:19.370
Mówisz: najpierw konstruuję to, potem
to, a potem konstruuję trzecią rzecz z

00:05:19.560,00:05:21.050
tych dwóch pierwszych.

00:05:21.390,00:05:24.060
I to nie jest "czasowe", to jest tak na
prawdę...

00:05:24.270,00:05:25.790
bardziej... bardziej jak przestrzeń.

00:05:26.090,00:05:28.710
 Jakbyście budowali strukturę z klocków
Lego, albo coś w tym rodzaju.

00:05:28.920,00:05:31.610
Gdybyście teraz do tego dodali
paralelizm...

00:05:31.810,00:05:33.900
Gdy się buduje coś w przestrzeni, to jest
to bardzo proste.

00:05:34.270,00:05:39.100
Możecie budować różne części
ostatecznego rozwiązania po prostu w

00:05:39.340,00:05:40.770
różnych procesach.

00:05:40.970,00:05:45.950
To jest jak, gdy setka ludzi buduje
jednocześnie katedrę

00:05:46.180,00:05:49.160
Nie wchodzą sobie w drogę, bo zwykle
każdy buduje swoją kolumnę albo część

00:05:49.390,00:05:51.360
tej katedry.

00:05:51.570,00:05:54.300
  Ale jeśli myśleć w kategoriach
czasowych, rzeczy robią się bardziej

00:05:54.550,00:05:56.510
skomplikowane, bo mamy wiele wątków
kontroli

00:05:56.890,00:05:59.490
i mają one tendencje do splatania się w
trudne węzły.

00:05:59.890,00:06:02.470
Te węzły nazywane są deadlockami, albo
gonitwami, itp.

00:06:02.830,00:06:07.850
Więc im więcej tego robicie, tym trudniej
jest utrzymać wszystko w porządku.

00:06:08.280,00:06:14.610
Więc co ludzie robią, to wkładają w to
struktury kontrolne jak locki, regiony

00:06:15.010,00:06:18.350
atomowe, albo pamięci transakcyjne itp.

00:06:18.820,00:06:22.050
I to jest bardzo użyteczne. Niektóre z nich
są bardziej użyteczne niż inne

00:06:22.430,00:06:26.450
ale podstawowym problemem jest, że
właściwie wkładacie te struktury, żeby

00:06:26.680,00:06:28.730
powstrzymać przypływ...

00:06:28.990,00:06:32.700
Mam tak wiele możliwych ścieżek
wykonania i muszę je kontrolować.

00:06:33.060,00:06:36.110
Muszę wyrugować złe kombinacje
wątków.

00:06:36.460,00:06:39.390
Jest też coś w czym my programiści,
albo generalnie ludzie tak myślę,

00:06:39.710,00:06:42.190
jesteśmy kiepscy.

00:06:42.570,00:06:44.600
Jesteśmy optymistycznymi zwierzętami.

00:06:45.040,00:06:46.350
Chcemy osiągać rzeczy.

00:06:46.830,00:06:49.890
Mówimy: chcę skonstruować mój
program, aby osiągnąć ten cel

00:06:50.160,00:06:52.300
nie będę wznosił tych ścian, żeby
trzymać wszystkie złe rzeczy na

00:06:52.620,00:06:53.850
zewnątrz.

00:06:54.240,00:06:55.690
Dlatego uważam podstawowo...

00:06:56.000,00:06:57.740
w programowaniu współbieżnym... 

00:06:58.380,00:06:59.890
w kategoriach czasowych...

00:07:00.510,00:07:01.880
to znaczy imperatywnie...

00:07:02.520,00:07:04.260
to jest bardzo, bardzo trudne. 

00:07:04.800,00:07:05.730
Więc to jest podstawowy problem.

00:07:06.110,00:07:08.530
Jak zamierzamy obsłużyć to w Scali?

00:07:08.940,00:07:10.690
Scala jest właściwie... eee...

00:07:11.030,00:07:14.700
Na tym slajdzie nie widać niczego co
miałoby coś wspólnego ze

00:07:15.200,00:07:16.860
współbieżnością czy konkurencją....

00:07:17.170,00:07:19.520
Scala jest właściwie językiem, który łączy
bardziej niż jakikolwiek inny język (tak

00:07:20.000,00:07:22.790
myślę) funkcyjny i obiektowy styl
myślenia.

00:07:23.220,00:07:26.900
Niektórzy mówią, że obiektowy styl
myślenia jest jakimś spadkiem i Scala

00:07:27.240,00:07:30.180
używa go, żeby  przyciągnąć
programistów Javy.

00:07:30.520,00:07:34.430
I za każdym razem, gdy ktoś powie coś
takiego, ja mówię: "nie! to wcale nie tak!"

00:07:34.810,00:07:37.840
Dla nas programowanie obiektowe jest
tak samo ważne jak programowanie

00:07:38.220,00:07:39.530
funkcyjne.

00:07:40.350,00:07:43.620
I uważam, że główne innowacje w Scali
pochodzą z obszaru programowania

00:07:44.320,00:07:46.010
obiektowego, a nie funkcyjnego.

00:07:46.390,00:07:50.430
Więc to co można osiągnąć za pomocą
tej kombinacji, to bardzo, bardzo

00:07:50.680,00:07:51.710
elastyczny język.

00:07:52.190,00:07:55.060
Język, który skaluje się z pojedynczej
linii programów REPL do programów o

00:07:55.380,00:07:59.540
setkach tysięcy linii, do infrastruktury
Twittera.

00:08:00.040,00:08:04.590
Co jeszcze można uzyskać, to język,
który z powodu posiadania z jednej

00:08:04.980,00:08:11.060
strony programowania funkcyjnego, które
jest ważne z powodu współbieżności, jak

00:08:11.480,00:08:15.850
już zauważyliście, 

00:08:16.230,00:08:18.640
a z drugiej strony potężny, obiektowo
zorientowany sposób komponowania

00:08:19.020,00:08:21.810
rzeczy, możecie pisać na prawdę piękne
oprogramowanie współbieżne i

00:08:22.210,00:08:23.010
konkurencyjne.

00:08:23.350,00:08:24.590
Więc.. że... eee...

00:08:24.970,00:08:26.660
..tylko żeby pokazać, gdzie jesteśmy
obecnie...

00:08:27.150,00:08:29.030
...kupa użytkowników. Widzieliście
Twittera i jest wielu innych.

00:08:29.390,00:08:32.550
Gdzie są Główne wektory zastosowań  i
skąd pochodzą?

00:08:33.160,00:08:38.470
Są platformy webowe, jak Twitter,
również platformy zakupowe.

00:08:38.890,00:08:42.420
Obie są typowo mocno konkurencyjnymi
problemami.

00:08:42.740,00:08:47.820
Dalej jest modelowanie finansowe, które
typowo jest bardziej problemem

00:08:48.270,00:08:49.260
zrównoleglenia

00:08:49.700,00:08:53.050
To znaczy jest to bardzo intensywne
obliczeniowo program, ale nie jest

00:08:53.500,00:08:54.410
charakterystycznie konkurencyjny.

00:08:54.980,00:08:57.390
Dalej jest też symulacja.

00:08:57.810,00:08:59.850
Więc wiele tych głównych wektorów
zastosowania Scali pochodzą z tych

00:09:00.230,00:09:01.090
obszarów.

00:09:01.400,00:09:05.390
I generalnie główną zaletą w porównaniu
do innych rozwiązań jest to, że Scala jest

00:09:05.630,00:09:08.720
zarówno językiem, który jest bardzo
szybkim do pierwszego produktu,

00:09:08.940,00:09:12.200
ponieważ jest lekki, zwinny i bardzo
skalowalny później.

00:09:12.540,00:09:16.950
Zestawem narzędzi dla konkurencji i
paralelizmu jest to, że mamy na prawdę

00:09:17.370,00:09:21.130
różne narzędzia dla tych dwóch
zastosowań.

00:09:21.610,00:09:25.990
Dla zrównoleglenia bazujemy w
większości obecnej pracy na kolekcjach. 

00:09:26.220,00:09:30.260
Uważamy, że kolekcje są wspaniałym
sposobem na wyrażenie obliczeń

00:09:30.640,00:09:34.160
równoległych, więc mamy podstawowe
kolekcje i kolekcje równoległe i również

00:09:34.390,00:09:38.200
rozproszone kolekcje i wykonujemy je na
[niezrozumiałe] itp.

00:09:38.610,00:09:42.260
Na dłuższą metę przyglądamy się
równoległym językom specyficznym dla

00:09:42.510,00:09:43.770
pewnych dziedzin (DSL).

00:09:44.270,00:09:47.760
Dla konkurencyjności mamy formalizm,
który jest dość szeroko używany w tej

00:09:47.950,00:09:49.150
dziedzinie. To są aktorzy

00:09:49.380,00:09:53.270
i są oni uzupełnieni o inne technologie,
jak pamięć wymienialna programowo i

00:09:53.510,00:09:57.010
przyszłości (Futures) w pakiecie Akka,
nad którym również pracujemy w

00:09:57.380,00:09:58.380
Typesafe.

00:09:58.840,00:10:05.490
Jeśli spojrzycie na ten mały przykład... to
jest klasa Javy... tak dla wprowadzenia.

00:10:05.830,00:10:10.420
Każdy wie co to robi, prawda? Osoba z
imieniem i wiekiem.

00:10:10.910,00:10:16.680
W Scali jest to bardziej kompaktowe,
więc mamy tę samą klasę tylko bez

00:10:16.900,00:10:17.880
powtórzeń.

00:10:18.220,00:10:23.150
Więc w Javie używamy wszystkiego trzy
razy, a Scali tylko raz.

00:10:23.600,00:10:24.740
OK. Więc...

00:10:25.090,00:10:27.570
Zróbmy coś z tą klasą...

00:10:27.750,00:10:28.850
Co z nią zrobimy?

00:10:29.100,00:10:33.750
Ta rzecz, jeśli przyjrzycie się temu
dostatecznie długo, na co nie mamy

00:10:33.940,00:10:34.850
czasu,

00:10:35.110,00:10:40.010
sortuje tablicę osób na nieletnich i
dorosłych zależnie od wieku.

00:10:40.400,00:10:43.750
OK. Całkiem sporo kodu, ale
przyzwyczailiśmy się do tego. Możemy to

00:10:43.990,00:10:46.270
napisać bardzo szybko.

00:10:46.730,00:10:51.010
W Scali jest to dużo bardzie kompaktowe
i bardziej jasne.

00:10:51.280,00:10:55.060
I uważam, że, nawet jeśli jesteście
przyzwyczajeni do składni javowej, to

00:10:55.380,00:10:58.630
przyznacie, że jest to o wiele prostsze.

00:10:59.110,00:11:02.390
Więc co tu robimy to bierzemy tablicę
osób 

00:11:02.720,00:11:09.390
i mówimy: weź tę tablicę i partycjonuj ją
zgodnie z wiekiem i to daje mi nieletnich

00:11:09.600,00:11:11.590
i dorosłych w dwóch niezmiennych
wartościach.

00:11:12.000,00:11:17.110
I to w pigułce pokazuje już trzy
podstawowe elementy funkcjonalne, jakie

00:11:17.490,00:11:19.660
mamy w Scali.

00:11:20.100,00:11:23.790
Po lewej stronie widzimy dekompozycję
wyniku na dwie wartości.

00:11:24.080,00:11:26.200
To jest prosta forma znajdowania
wzorców.

00:11:26.520,00:11:30.430
Metoda 'partition' jest wywołaniem typu
'infix' dla tablicy.

00:11:30.860,00:11:36.740
I ta metoda pobiera funkcyjny argument,
który jest domknięciem, a które będą

00:11:36.940,00:11:39.130
dostępne prawdopodobnie w Java 8.

00:11:39.310,00:11:41.390
Scala miała je oczywiście od samego
początku.

00:11:41.590,00:11:45.120
Więc to jest bardzo krótki sposób na
zapis domknięcia, które mówi również:

00:11:45.540,00:11:48.520
"daj parametr". To jest to podkreślenie
tutaj.

00:11:48.760,00:11:51.970
"Weź jego wiek i porównaj ten wiek do
18."

00:11:52.260,00:11:54.810
I to jest rzecz, którą przekazuje się
metodzie "partition".

00:11:55.270,00:11:57.860
OK. Możecie powiedzieć: "to jest
przyjemnie proste, ale co ze

00:11:58.120,00:11:59.300
współbieżnością?"

00:11:59.560,00:12:01.220
Co to ma wspólnego ze współbieżnością?

00:12:01.610,00:12:04.410
Więc zróbmy znowu to samo, ale
zrównoleglając.

00:12:04.800,00:12:07.240
W Javie? Jak byście to zrobili?

00:12:09.410,00:12:10.700
Niezbyt proste, prawda?

00:12:11.910,00:12:13.730
Jak długo by to wam zajęło? 

00:12:14.030,00:12:15.010
Jeden dzień? 

00:12:15.280,00:12:16.780
Może? Jeśli jesteście dobrzy...

00:12:17.040,00:12:19.680
Zrobić parę wątków, locków,
synchronizacji itp.

00:12:20.340,00:12:21.900
Oto co robicie w Scali:

00:12:22.400,00:12:25.570
po prostu dodajecie ".par" do "people"

00:12:25.950,00:12:26.910
i to wszystko.

00:12:27.470,00:12:31.620
".par" przetwarza tablicę "people" w
rzecz nazywaną "ParArray" 

00:12:32.090,00:12:35.460
i wtedy...eee... Tablice zrównoleglone
mają dokładnie te same operacje, co

00:12:35.680,00:12:38.380
normalne tablice

00:12:38.580,00:12:40.700
a szczególnie mają też metodę "partition"

00:12:40.950,00:12:42.750
i to oznacza, że wszytko teraz działa
równolegle.

00:12:43.190,00:12:47.540
Więc to jest raczej spoko i... ponieważ
otrzymujecie bardzo tanią poprawę

00:12:47.780,00:12:49.610
wydajności z tych zrównoleglonych
kolekcji.

00:12:49.980,00:12:55.820
Ale to nie wszystko w tej historii, bo
czasami potrzebujecie kontroli nad

00:12:56.120,00:12:56.890
wątkami

00:12:57.380,00:13:00.730
Chcecie mieć wątki, które mogą się nie
powieźć.

00:13:01.060,00:13:03.550
Chcecie mieć precyzyjną kontrolę nad
ilością wątków, jak się one komunikują

00:13:03.740,00:13:04.570
itd.

00:13:04.790,00:13:06.060
Wiec co robimy w takim przypadku?

00:13:06.510,00:13:10.610
Inną częścią, jaką oferuje Scala są
aktorzy.

00:13:10.980,00:13:15.640
Więc tutaj po prawej stronie mamy prosty
program, który zaczyna się taka jak ten

00:13:15.830,00:13:17.020
pierwszy program

00:13:17.300,00:13:20.070
tylko, że potem komunikuje się on z
innymi aktorami, używając

00:13:20.300,00:13:21.680
przekazywania wiadomości.

00:13:21.960,00:13:23.680
Ten aktor tutaj będzie odbierał...

00:13:23.920,00:13:28.720
...akceptuje jako wiadomość zbiór osób,
zwany "people"

00:13:29.070,00:13:30.620
Dalej dokonuje podziału.

00:13:30.950,00:13:33.690
Możemy to zrobić równolegle lub
sekwencyjnie, to nie jest ważne, jak te

00:13:33.860,00:13:35.440
rzeczy są skomponowane.

00:13:35.730,00:13:38.270
I dalej przesyła nieletnich do fejsbuka, a
dorosłych do LinkedIn.

00:13:38.470,00:13:42.900
To daje wam bardzo prosty i
wysokopoziomowy model przesyłania

00:13:43.260,00:13:44.390
wiadomości

00:13:44.660,00:13:46.560
który jest bardzo użyteczny, jeśli...

00:13:46.740,00:13:47.650
wy... 

00:13:47.840,00:13:48.760
eee... 

00:13:48.990,00:13:49.900
szczególnie... 

00:13:50.130,00:13:51.180
eee...

00:13:51.390,00:13:54.560
Macie pełno komunikacji pomiędzy
rzeczami, które mogą być daleko od

00:13:54.780,00:13:55.600
siebie.

00:13:55.920,00:13:58.430
Więc ten sam model wiadomości działa
przez Internet albo w klastrze, albo

00:13:58.660,00:14:02.920
pomiędzy kilkoma procesami w jednym
rdzeniu.

00:14:03.150,00:14:06.720
Jeszcze powinienem powiedzieć, że
dzisiaj mam jedno wystąpienie o

00:14:06.900,00:14:08.790
kolekcjach i jedno o aktorach.

00:14:09.400,00:14:12.110
Pytanie brzmi: gdzie to się zatrzymuje?

00:14:12.580,00:14:19.300
Jeśli spojrzycie na dzisiejszy obecny
sprzęt, to potrzebne są dziesiątki tysięcy

00:14:19.590,00:14:24.180
wątków żyjących na komputerze, jeśli
chcemy mieć pożytek z nowoczesnych

00:14:24.440,00:14:25.630
jednostek centralnych.

00:14:25.990,00:14:27.290
Więc jak to robimy?

00:14:27.720,00:14:30.240
Mamy bardzo duży projekt razem z
ludźmi ze Stanford

00:14:30.650,00:14:33.950
który pracuje z równoległymi,
osadzonymi językami specyficznych

00:14:34.230,00:14:35.710
zastosowań.

00:14:36.190,00:14:38.430
Idea jest taka, że jeśli chcemy to zrobić,

00:14:38.830,00:14:43.970
to stawianie na kompilator, żeby sam
automatycznie zrównoleglił twoje rzeczy,

00:14:44.360,00:14:46.260
nie działa.

00:14:46.600,00:14:49.510
Kompilatory nie są wystarczająco mądre.
Programy nie są typowo wystarczająco

00:14:49.670,00:14:50.990
zrównoleglone.

00:14:51.460,00:14:54.180
Ale co można zrobić, to w każdej
domenie 

00:14:54.520,00:14:56.990
napisać język specyficznych zastosowań
dla tej domeny, taki jak

00:14:57.400,00:15:00.220
naukowy, inżynierski, renderujący itp.

00:15:00.550,00:15:05.160
I te języki mogą być zoptymalizowane
specyficzny dla swojej domeny sposób.

00:15:05.430,00:15:07.730
Ponieważ w danej domenie wiecie, gdzie
występuje paralelizm.

00:15:08.140,00:15:10.180
Pozwólcie, że podam przykład.

00:15:10.610,00:15:14.080
To jest Liszt  - język DSL do symulacji
zjawisk fizycznych, który został

00:15:14.300,00:15:15.790
stworzony w Stanford.

00:15:16.040,00:15:19.330
Jedną rzeczy, którą robią jest symulacja
ponaddźwiękowego silnika odrzutowego.

00:15:19.660,00:15:23.170
To jest właśnie obraz wejścia strumienia
odrzutowego.

00:15:23.610,00:15:27.490
Ogromna liczba domen, około miliona
komórek muszą być symulowane.

00:15:27.700,00:15:30.070
Bardzo nieregularne domeny, również.

00:15:30.500,00:15:32.690
Więc to jest program, który to robi.

00:15:32.940,00:15:36.250
Jeśli spojrzycie na to, to jest czysta
Scala. To wygląda jak Scala.

00:15:36.590,00:15:39.000
To używa scalowe abstrakcje sterowania.

00:15:39.360,00:15:42.190
'untilconverge' to jest funkcja
zdefiniowana przez użytkownika,

00:15:42.540,00:15:46.680
która używa jakiegoś wewnętrznego
sposobu propagacji przebiegu danych 

00:15:47.060,00:15:51.100
Ale to co się dzieje pod powierzchnią, to
nie jest to, że program w Scali jest

00:15:51.400,00:15:53.080
uruchamiany bezpośrednio.

00:15:53.400,00:15:56.440
Ale zamiast tego program w Scali
generuje sam siebie jako abstrakcyjne

00:15:56.730,00:15:58.290
drzewo składniowe

00:15:58.790,00:16:02.170
Prześle siebie do optymalizatora i ten
optymalizator weźmie ten program i

00:16:02.450,00:16:04.260
sprzęt, i rozmiar problemu 

00:16:04.670,00:16:09.430
i wygeneruje tu zoptymalizowany
program.

00:16:09.930,00:16:13.470
I już zademonstrowaliśmy, że ta rzecz
może pobić pisany ręcznie kod C     na tym

00:16:13.830,00:16:16.060
samym klastrze.

00:16:16.280,00:16:19.400
Więc to jest całkiem imponujące.

00:16:19.690,00:16:22.310
To jest wszystko co mam w keynote
(myśl przewodnia). Będą jeszcze dwa

00:16:22.690,00:16:24.980
wystąpienia później tego popołudnia.

00:16:25.410,00:16:27.270
Gdzie powiem wam trochę więcej o
szczegółach.

00:16:27.650,00:16:29.830
Dziękuję.