Pobierać i cieszyć się ;)
- Rejestracja:prawie 20 lat
- Ostatnio:około 3 godziny
5
Zobacz pozostałe 6 komentarzy
byku_guzio
no to Wibowit się do tego nie nadaje bo od razu wyciągnie scale z rękawa i tyle z porównania javy i cpp :D
O_o
Nie ma to jak framework we frameworku ;p
Krolik
Benchmarki zwykle nie odzwierciedlają rzeczywistego zastosowania, a w rzeczywistych zastosowaniach nigdy jeszcze nie zdarzyło mi się, aby Java była przyczyną zbyt powolnego działania aplikacji. Np. nasz silnik symulatora elektroniki napisany w Scali działa znacznie szybciej niż kod SPICE 3 napisany w C, więc Java/Scala na pewno należą do kategorii szybkich języków, tak jak C++ i C.
msm
Cieszcie się, cieszcie :> Btw. O_o -> Java przeprowadza optymalizacje o których C++ owcom się nawet nie śni... A C# (jeszcze) nie potrafi.
Krolik
Ciekawe optymalizacje to się zaczną jak zoptymalizują invokedynamic w sposób opisany tutaj: http://www.azulsystems.com/blog/cliff/2011-04-04-fixing-the-inlining-problem. Dzięki temu wszędzie tam, gdzie C++ dla osiągnięcia pełnej wydajności trzeba było używać szablonów i rezygnować z powolnych wywołań wirtualnych, w Javie wystarczy pozostawić wirtualne tak jak były, JVM dokona specjalizacji ze względu na typ automatycznie, ale lepiej niż kompilatory szablonów w C++ bo z mniejszym narzutem na rozmiar kodu.
- Rejestracja:prawie 15 lat
- Ostatnio:około 7 lat
0
O_o muszę przyznać, że się nie spodziewałem dotrzymania terminu. Jak zapowiedzieli wydanie 28go tak wyszło. Jest coś nowego poza nio, dodatkowych rzeczy związanych z concurrency i switch'a obsługującego stringi? Nie mam jakoś teraz siły szukać info o tym ;)
//edit: dobra, nie było pytania:
http://openjdk.java.net/projects/jdk7/features/
//edit2: i już nawet zapowiedź odnośnie JDK 8: podoba mi się "JSR 296: Swing application framework" - NetBeans Platform nie bardzo się nadaje do drobnych aplikacji(jest raczej wytaczaniem baterii dział na muche) ;)
edytowany 4x, ostatnio: byku_guzio
Zobacz pozostałe 11 komentarzy
Ja C++ starałem się omijać jak najdłużej, znajomość gołego C bardzo się przy tym przydawała :D
Pomijając jakąś krótką przygodę z pascalem to c++ był moim pierwszym językiem(i niestety za długo jedynym - przez to uważałem, że jest osom, wypas i w ogóle najlepszy <facepalm>) no ale początki były grube lata temu :)
Każdy ma jakies wady :>
xDDD
"W JDK 7 domyślnie jest G1 GC zamiast dotychczasowego CMS GC" - zwariowali?! Jeszcze nie widziałem aplikacji, w której G1 działałby lepiej niż CMS.
- Rejestracja:prawie 20 lat
- Ostatnio:około 3 godziny
0
ROFL, nie mogę własnego postu zedytować. Tak więc, na testy trzeba poczekać. Tu: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.63.6386&rep=rep1&type=pdf jest bardzo stary test G1 GC, wynika z niego, że pauzy są znacznie mniejsze niż w przypadku CMS GC. Poza tym możecie sobie wyguglować frazę "dual pivot quicksort", czyli wariacja quicksorta, która będzie użyta w JDK 7. Wydaje mi się, że kilka eksperymentalnych (tzn o takim statusie) rzeczy z JDK 6 będzie domyślnie włączone w JDK 7.
Pauzy są mniejsze, ale G1 jest bardzo łatwo wtrącić w taki tryb pracy, że co 0.001 sekundy robi pauzy trwające 0.002 sekundy. Poza tym dla wielu aplikacji G1 wymaga bardzo dużego narzutu pamięciowego, inaczej powoduje znaczny narzut CPU.
- Rejestracja:prawie 15 lat
- Ostatnio:około 7 lat
0
"wynika z niego, że pauzy są znacznie mniejsze niż w przypadku"
to dobrze. Chociaż imho w Javie nie tyle jest ważna optymalizacja co maksymalna wysokopoziomowość. Mogę się okrutnie mylić(brak doświadczenia - ot tak obserwacja), ale wydaje mi się, że w zastosowaniach w których używa się javy wydajność nie jest priorytetem: w systemach real-time i tak nie bardzo się nadaje, a w systemach biznesowych, czy dla zwykłych użyszkodników się sprawdza.
Od dawna wiadomo że wydajności to tu nie ma więc jako zaletę trzeba wypychać wysokopoziomowość ;)
no ale chyba twórcy javy nie myśleli sobie(te kilka lat temu jak to ustrojstwo tworzyli), że język na tak wysokim poziomie dorówna wydajnością językom aka c/c++. Po prostu inna domena problemów jest przeznaczona dla tych języków. I chyba tak powinno być w myśl zasady: co jest do wszystkiego jest do niczego :)
- Rejestracja:prawie 20 lat
- Ostatnio:około 3 godziny
0
Java jest kilkadziesiąt procent wolniejsza od C++, więc aby uzyskać taką samą wydajność wystarczy podwoić liczbę procesorów. Stara prawda głosi, że koszt sprzętu jest nieporównywalnie niższy niż koszt programistów, więc i tak biznes wychodził by na plus. Javy się jednak w systemach real-time zbyt często nie używa ponieważ JVMy zżerają kilkanaście/ kilkadziesiąt MB RAMu na starcie, a do wydajnej pracy wymagają wielokrotnie więcej oraz dlatego (to jest największy powód), że oprócz kilku pewnie eksperymentalnych i płatnych JVMów, żaden nie daje ścisłej gwarancji na długość pauzy przy odśmiecaniu. Ciężko więc stosować Javę np w komputerach pokładowych samochodów.
O_o:
Podaj mi jakiś problem w którym 100 % Javowy kod jest drastycznie wolniejszy od 100 % C++owego kodu.
edytowany 1x, ostatnio: Wibowit
Problem gdzie Java jest wolniejsza hmmm, uruchomienie się choćy :> Nie robię w Dżabie więc nic niekawego nie podam ale sam chyba znasz takich przykładów sporo ;) Ja to tak tylko z pozycji obserwatora odczuwam przymuły.
dopiero odpalenie aplikacji w netbeans platform zajmuje czas. To jest masakra :D
No ale z drugiej strony programy w C++ są zwykle mniej funkcjonalne. No i JVM dostarcza mnóstwa własnych mechanizmów, dublujących niejako te, które są w systemie czyli start JVM to tak jakby start systemu. Tu: http://www.excelsior-usa.com/java-startup-time.html jest małe porównanie czasu odpalania, chociaż nie wiem jak się prezentuje funkcjonalność RSSOwl na tle konkurencji. Po odpaleniu jednak aplikacje Javowe dają radę :)
Dodatkowym problemem z Dżabą są jej programiści, platforma ta odczuwa "efekt Delphi", jak już znajde jakiś program w javie który mi się przydaje ( ostatnio kalkulator do funkcji wielu zmiennych z wizualizacją ) to po pierwszym szoku "to działa! I nawet da się używać!" nadchodzą pierwsze bugi i wkrótce nieunikniony "division by zero" ...
Tia, bo liby w C++, to błędów nie mają... W Javie przynajmniej dostajesz w takiej sytuacji pełny stacktace a nie "segmentation fault". Średnia jakość programistów jest podobna - tzn. większość jest kiepska, i nie ma znaczenia czy C++ czy Java. Większość się uczy C++/Javy/C# bo musi na studiach, albo bo liczą na kasę, a nie dlatego że lubią.
- Rejestracja:prawie 15 lat
- Ostatnio:około 7 lat
0
Tyle, że ta słabsza wydajność nie jest raczej problemem. Przynajmniej w zwykłych biznesowych aplikacjach. To jest po prostu odpowiedni wybór języka biorąc pod uwagę koszt kodu, sprzętu i wymagania, ograniczenia.
W jednym przypadku lepiej się sprawdzi Java w innym C++, a w innym jeszcze coś innego - i to by było na tyle z filozofii i fanboizmu ;)
Ostatnio pisałem coś w c++ co raczej w javie byłoby ciężej zrobić. Ot taka drobna app z 5 kontrolkami na krzyż, ale musiała wywoływać funkcje czystego WinAPI - zdenerwowałem się na typa w robocie, bo od roku czekaliśmy na poprawki do aplikacji dla działu helpdesk, to sam dopisałem funkcjonalności(typowi nawet się głupiego zapytania do bazy nie chciało poprawić).
Forumowy kolega lipkerson zajmuje się zabawą w WinAPI z poziomu Javy i dobrze mu to idzie. Choć niekoniecznie jest to dobry sposób postępowania.
Zło. Wołanie funkcji natywnych z frameworku jest z definicji złe. Ale że czasem trzeba to inna sprawa ;)
No ale jak tych funkcji masz wywołać 3 na krzyż(jakieś findwindow, sendmessage...) to zaprzęganie do tego takiego JNI to przesada. ;)
Niekiedy ianczej trudno to zrobić, np pobranie bramy domyślnej z jakiegoś powodu w żabie nie występuje x.x
- Rejestracja:ponad 13 lat
- Ostatnio:około 13 lat
- Postów:98
0
W tym porównaniu szybkości uruchamiania jedna aplikacja jest zoptymalizowana.
Z tego co wyczytałem to jest to optymalizacja pod daną platformę więc wyklucza możliwość przenoszenia, zgadza się? Cięzko mi się połapać trochę w informacjach o Javie stąd kolejne pytanko: Jest to optymalizacja pod daną rodzinę procesorów czy konkretnie dany sprzęt? Słyszałem kiedyś pogłoski że daje radę w tym zoptymalizować pod konkretny model ale tematu jakoś nie zgłębiałem.
Masz może jakiś pdfik dla laika w dziedzinie Dżaby który opisał by takie ciekawostki w miarę przystępnie?
O! Bo ciężko mi coś użytecznego wygoglować, jest jakaś przystępna paczuszka pozwalająca na normalną obsługe ekranów dotykowych w J2ME czy ni hu hu?
edytowany 1x, ostatnio: O_o
0
http://mail-archives.apache.org/mod_mbox/lucene-java-user/201107.mbox/%3C001601cc4d6b$37618880$a6249980$@apache.org%3E
http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2011-July/005971.html
Bardzo podoba mi sie zdanie:
"(...) it contains hotspot compiler optimizations, which** miscompile** some loops (...)"
Prawdopodobnie jest wiele kodu ktory na jdk7 kleka. Miejmy nadzieje ze bug zostanie napawiony szybciej niz poprzedni glosny bug z parsowaniem flatow ktory sie nie konczyl bo wpadal w nieskonczona petle.
- Rejestracja:prawie 20 lat
- Ostatnio:około 3 godziny
0
O_o:
Gdzieś ty takie rzeczy wyczytał? Kod Javowy jest kompilowany do bajtkodu, który jest w zasadzie kodem natywnym dla pewnej maszyny i są nawet procesory, które wykonują bezpośrednio bajtkod Javowy. Tyle, że to rozwiązania niszowe i eksperymentalne, wykonywanie bajkodu wprost jest i będzie wolne. Dlatego tworzy się maszyny wirtualne, które są tak jakby emulatorami tego Javowego procesora. Owa maszyna wirtualna tłumaczy bajtkod na kod natywny procesora na której jest odpalana i ma za zadanie jak najbardziej zoptymalizować kod pod ten procesor. Nie słyszałem natomiast o optymalizacji bajtkodu pod jakiś procesor :P
"W JDK 7 domyślnie jest G1 GC zamiast dotychczasowego CMS GC" - zwariowali?! Jeszcze nie widziałem aplikacji, w której G1 działałby lepiej niż CMS.
Masz jakieś benche? W sumie to nie jest pewne, czy od razu G1 zastąpi CMS, chyba przesunęli terminy i G1 będzie domyślny w którymś tam updacie. Tak przynajmniej wynika z: http://www.slideshare.net/myfear/introducing-java-7 (slajd 42)
http://download.oracle.com/javase/7/docs/technotes/guides/vm/G1.html - tu też jest napisane, że G1 ma docelowo zastąpić CMS w JDK 7.
::.
Widać, że zapomnieli zatrudnić Egona.
edytowany 2x, ostatnio: Wibowit
Pisałem że w Javie to ja noob jestem ;) Dlatego się pytam speców ;)
JVM potrafi wykonywać wiele optymalizacji, których kompilatory C i C++ nie potrafią - np. inline'ować wywołania wirtualne (niebawem również megamorficzne), albo usuwać niepotrzebną synchronizację wątków. Stąd bardzo trudno stwierdzić, co jest szybsze - prosty kod benchmarków raczej nie używa synchronizacji czy wirtualnych wywołań, stąd Java dostaje trochę w plecy, ale w realnym, dużym kodzie, gdzie liczy się odpowiedni poziom abstrakcji, te optymalizacje mają duży wpływ. Porównaj sobie np, wydajność javowego H2 i C++ MySQL, MySQL dostaje bęcki.
1
Tak, mam benche swojej aplikacji (silnik numeryczny na ok. 5 tys. linii kodu) - po włączeniu G1 GC, o ile nie dam jej 100% więcej RAMu, chodzi wyraźnie wolniej.
Na CMS nie widać spowolnienia, nawet jeśli sterta jest tylko o 30% większa niż rozmiar żywych danych. Poza tym G1 GC ma tę samą wadę co CMS, i tak wcześniej czy później będzie musiał zrobić full-gc, to że to nastąpi później lub z mniejszym prawdopodobieństwem niż w przypadku CMS to żadna pociecha (a zapewne nastąpi, ponieważ blokujący kod full-gc nadal tam jest w G1, jeśli ten kod nie miałby być nigdy wywołany to po co tam jest?). Mimo to, teraz jak wyszło JDK7 dam szanse G1 jeszcze raz i wrzuce jakieś benchmarki.
StackOverflow napisał(a)
I've been testing it out with a heavy application: 60-70GB allocated to heap, with 20-50GB in use at any time. With these sorts of applications, it's an understatement to say that your mileage may vary. I'm running JDK 1.6_22 on Linux. The minor versions are important-- before about 1.6_20, there were bugs in G1 that caused random NullPointerExceptions.
I've found that it is very good at keeping within the pause target you give it most of the time. The default appears to be a 100ms (0.1 second) pause, and I've been telling it to do half that (-XX:MaxGCPauseMillis=50). However, once it gets really low on memory, it panics and does a full stop-the-world garbage collection. With 65GB, that takes between 30 seconds and 2 minutes. (The number of CPUs probably doesn't make a difference; it's probably limited by the bus speed.)
edytowany 4x, ostatnio: Krolik
Zobacz pozostały 1 komentarz
To po co jest tam ten kod? G1 nie fragmentuje, ale ma inne problemy, patrz cytat z SO.
Może jakiś tuning parametrów by pomógł. Albo w kolejnym updacie to rozwiążą.
Może i by pomógł, ale nie zmieni to faktu, że fallback do STW nadal tam jest. Oracle się musi trochę lepiej postarać, bo inaczej nikt nie będzie poważnie Javy traktował do zastosowań wymagających 50GB lub więcej RAM. Ja chcę GC bez ani jednej linijki kodu blokującego wątki aplikacji! Azul takie oferuje i chodzi miodzio (tylko kosztuje $$$), więc niech Oracle nie mydli oczu, że G1 to takie rewelacyjne osiągnięcie, bo technologicznie jest w tyle. :P
A jak z wydajnością tego Azul JVM? G1 jest soft real-time po to, aby nie zmniejszyć drastycznie wydajności (docelowo oczywiście ma tak być).
Wydajność jest bardzo zbliżona do CMS - bo to jest normalny dwugeneracyjny mark & compact GC, tyle że działający ciągle, bez zatrzymań, na osobnym rdzeniu (rdzeniach).
- Rejestracja:ponad 14 lat
- Ostatnio:prawie 11 lat
0
Z nowości można jeszcze wymienić reakcję na rolkę poziomego przewijania myszy:D Java 6 nie reagował w ogóle, natomiast Java 7 przy przewijaniu poziomym ciągle narzeka:
MEvent. CASE!
Problem jest w nowym java.awt.MouseEvent. Dokopałem się w źródłach, że tam poza oznaczeniem wyjęcia buttonu z modyfikatorów, czy co to miało tam być, jest zwyczajny println do stdout. Sam MouseEvent też dość wydłużony: 891 linii do 1171. Fragment odpowiedzialny za sypanie niewiele mówiącego kodu (jeden z konstruktorów MouseEvent, linia 761):
if (getModifiersEx() != 0) { //There is at least one more button in a pressed state.
if (id == MouseEvent.MOUSE_RELEASED || id == MouseEvent.MOUSE_CLICKED){
System.out.println("MEvent. CASE!");
shouldExcludeButtonFromExtModifiers = true;
}
}
Niby drobnostka, ale trochę to utrudni debugowanie stdouta czasami, mam nadzieję że to zakomentują, albo usuną.
Co prawda myszki z poziomą rolką nie mam (są one dla mnie trochę niewygodne i niepraktyczne), ale na touchpadzie mam włączone poziome przewijanie, które w firefoxie i innych programach działa normalnie.
Ciekawe ile jeszcze takich baboli jest w kodzie nowej siódemki... :\
- Rejestracja:prawie 15 lat
- Ostatnio:około 7 lat
0
Nie sądzę, żeby kiedyś można było odtwarzać MP3 od tak. Z prostej przyczyny - MP3 nie jest otwartym formatem. Z tego co się orientuje to za komercyjne wykorzystywanie tego formatu trzeba płacić, ale mogę się mylić.
http://en.wikipedia.org/wiki/MP3#Licensing_and_patent_issues
Zobacz pozostałe 6 komentarzy
C# jest rozwijane przez Microsoft, a jego biblioteki korzystają z bibliotek systemu (i odwrotnie bo na jedno wychodzi). Microsoft kupił licencję zbiorczą na MP3 do wszystkich wydawanych systemów Windows. I to cała tajemnica wbudowanego kodeka w system Windows (i tym samym bibliotek .NET, czyli m. in. C#).
A Delphiowy TMediaPlayer korzysta z playera z systemu więc tu też nie ma tego wewnątrz ale skoro Delphi robione było na Winiaka, a Winiak ma MP3 to po co się męczyć :)
JOrbis jest, powinien wystarczyć.
No niby tak, ale np. można zrobić jakoś w sposób przenośny odtwarzanie multimediów (mp3,avi) - tak jak np w wxWidgets jest WxMediaCtrl, czy w QT Phonon
Jeżeli dana biblioteka nie korzysta z systemowych natywów lub umie się dostosować do tych systemowych to problemu nie ma.
- Rejestracja:ponad 16 lat
- Ostatnio:23 dni
- Lokalizacja:Polska, Warszawa
- Postów:1058
0
A propos bibliotek JDK7 - czy ktokolwiek z was dokopał się może do możliwości uzyskania przez nową Javę informacji o ograniczeniach wiekowych konta użytkownika w systemie?
Pewnie będę zmuszony dołożyć to przez JNI, ale jeżeli taka możliwość została cichaczem dorzucona do nowej edycji to skróciłoby mi to cierpień z przenośnością. ;)
Ograniczenia wiekowe? A jest to wspierane przynajmniej przez GNU/ Linuksa, BSD, Windowsa, Unixa (jakiegoś popularnego), MacOSa i Solarisa? W ogóle co to za opcja?
Np. Windows 7 ma przypisany do konta usera wiek (to znaczy, że Win8 też będzie to miała), dzięki czemu aplikacja może zablokować swoje uruchomienie przy zbyt niskim wieku lub zmodyfikować swoje działanie. Na przykład gry mogą automatycznie dopasowywać treści do wieku posiadacza konta lub blokować swoje uruchomienie.
ps. GNU/Linux i inne 0,4% wynalazki archeologiczne, to z punktu widzenia userów martwe systemy. Ich własna ewolucja zakończyła się 20-30 lat temu i dzisiaj tylko naśladują zmiany jakie robi Microsoft w swoim systemie. Takie życie.
A więc jest to nieprzenośna w ogóle funkcjonalność. Unix (a przez to i pochodne) przede wszystkim został dobrze zaprojektowany od podstaw, dlatego nie wymaga takiej bolesnej ewolucji jak DOS -> Win16 -> Win32 -> itd Na komórkach Windows jest praktycznie nieobecny. http://en.wikipedia.org/wiki/Usage_share_of_operating_systems
80,83% wszystkich userów PC nie można zignorować bo to samobójstwo finansowe dla każdego wydawcy softu. A co do Unixa był świetnie zaprojektowany, ale w roku 1970. Dzisiaj, 40 lat później i po stworzeniu miliardów wierszy kodu należy od systemu (i softu w ogóle) wymagać trochę więcej. Systemy Unixowe są już niestety tylko ciekawostką archeologiczną. Obsługa użytkownika (szczególnie bez GUI) jest jak na dzisiejsze czasy moim zdaniem po prostu koszmarna.
A moim zdaniem praca na Ubu jest komfortowa :) Siedzę na Ubu cały czas i nie zamierzam wracać. Windowsa mam tylko do gier.
0
Zrobiłem taki mały benchmark: symulacja czasowa układu RLC podłączonego do sinusoidalnego źródła napięcia.
Na stdout była wypisywane liczba obliczonych punktów (wektorów) na sekundę podawana co sekundę oraz czas zmierzony po każdym teście składającym się z 500000 punktów.
java -server, 64bit, ustawienia domyślne, Core i5 @ 2.6 GHz, Windows 7 Professional
Wyniki:
Java 6 update 26:
Simulation performance pts/s: 1
Simulation performance pts/s: 2371
Simulation performance pts/s: 8209
Simulation performance pts/s: 15751
Simulation performance pts/s: 39246
Simulation performance pts/s: 34950
Simulation performance pts/s: 41692
Simulation performance pts/s: 43911
Simulation performance pts/s: 43859
Simulation performance pts/s: 43943
Simulation performance pts/s: 43846
Simulation performance pts/s: 44016
Simulation performance pts/s: 43717
Simulation performance pts/s: 43638
Simulation performance pts/s: 44211
14.240377077 s
Simulation performance pts/s: 42663
Simulation performance pts/s: 38008
Simulation performance pts/s: 41868
Simulation performance pts/s: 42144
Simulation performance pts/s: 42155
Simulation performance pts/s: 41223
Simulation performance pts/s: 42831
Simulation performance pts/s: 42899
Simulation performance pts/s: 42735
Simulation performance pts/s: 42535
Simulation performance pts/s: 42739
Simulation performance pts/s: 42986
11.904730364 s
Simulation performance pts/s: 43221
Simulation performance pts/s: 42826
Simulation performance pts/s: 42642
Simulation performance pts/s: 42495
Simulation performance pts/s: 41560
Simulation performance pts/s: 43457
Simulation performance pts/s: 43849
Simulation performance pts/s: 43600
Simulation performance pts/s: 43591
Simulation performance pts/s: 43566
Simulation performance pts/s: 43566
11.610982254 s
Simulation performance pts/s: 42655
Simulation performance pts/s: 42505
Simulation performance pts/s: 41495
Simulation performance pts/s: 43020
Simulation performance pts/s: 42548
Simulation performance pts/s: 42754
Simulation performance pts/s: 42595
Simulation performance pts/s: 42788
Simulation performance pts/s: 43104
Simulation performance pts/s: 42866
Simulation performance pts/s: 43012
Simulation performance pts/s: 42425
11.740413788 s
Java 7:
Simulation performance pts/s: 1
Simulation performance pts/s: 1256
Simulation performance pts/s: 5383
Simulation performance pts/s: 7478
Simulation performance pts/s: 34277
Simulation performance pts/s: 37591
Simulation performance pts/s: 40700
Simulation performance pts/s: 46821
Simulation performance pts/s: 46547
Simulation performance pts/s: 46541
Simulation performance pts/s: 46179
Simulation performance pts/s: 46861
Simulation performance pts/s: 46541
Simulation performance pts/s: 46902
Simulation performance pts/s: 46799
15.242918744 s
Simulation performance pts/s: 43785
Simulation performance pts/s: 36187
Simulation performance pts/s: 43974
Simulation performance pts/s: 44391
Simulation performance pts/s: 42963
Simulation performance pts/s: 45212
Simulation performance pts/s: 45355
Simulation performance pts/s: 45192
Simulation performance pts/s: 45199
Simulation performance pts/s: 45304
Simulation performance pts/s: 45516
11.381108938 s
Simulation performance pts/s: 45702
Simulation performance pts/s: 45305
Simulation performance pts/s: 45105
Simulation performance pts/s: 45182
Simulation performance pts/s: 45457
Simulation performance pts/s: 46484
Simulation performance pts/s: 46595
Simulation performance pts/s: 46146
Simulation performance pts/s: 46285
Simulation performance pts/s: 45011
Simulation performance pts/s: 46163
10.936893744 s
Simulation performance pts/s: 45238
Simulation performance pts/s: 45005
Simulation performance pts/s: 45240
Simulation performance pts/s: 45281
Simulation performance pts/s: 45204
Simulation performance pts/s: 45014
Simulation performance pts/s: 45714
Simulation performance pts/s: 44167
Simulation performance pts/s: 45297
Simulation performance pts/s: 45350
Simulation performance pts/s: 45421
11.081033702 s
Widać, że jest różnica, ale niewielka, jeśli weźmiemy pod uwagę najlepszy z każdych przebiegów, to wychodzi, że różnica w tym teście jest ok. 6% na korzyść JDK7.
Oczywiście to jest tylko jeden test, więc daleko idących wniosków wyciągać nie należy, ale przynajmniej nie jest to microbenchmark (bo tam jest tego kodu dość dużo). Dzięki temu fajnie widać, jak się HotSpot rozpędza.
Dla -client nie sprawdzę, bo chyba nie ma Javy client dla 64 bitowego systemu (albo u mnie nie działa - nie widzę różnicy między client a server na tym sprzęcie).
Aktualizacja:
Sprawdziłem jak się zachowuje ten nowy wynalazek G1 GC. Na ustawieniach domyślnych, tj. java -server -XX:+UseG1GC jest cienko:
Simulation performance pts/s: 1
Simulation performance pts/s: 1295
Simulation performance pts/s: 4844
Simulation performance pts/s: 7846
Simulation performance pts/s: 19222
Simulation performance pts/s: 33578
Simulation performance pts/s: 28646
Simulation performance pts/s: 32418
Simulation performance pts/s: 35742
Simulation performance pts/s: 35511
Simulation performance pts/s: 35657
Simulation performance pts/s: 35381
Simulation performance pts/s: 35548
Simulation performance pts/s: 35300
Simulation performance pts/s: 35265
Simulation performance pts/s: 35686
Simulation performance pts/s: 35577
Simulation performance pts/s: 35433
18.713036112 s
Simulation performance pts/s: 35626
Simulation performance pts/s: 31817
Simulation performance pts/s: 26987
Simulation performance pts/s: 33687
Simulation performance pts/s: 33649
Simulation performance pts/s: 33937
Simulation performance pts/s: 33599
Simulation performance pts/s: 34024
Simulation performance pts/s: 33848
Simulation performance pts/s: 34004
Simulation performance pts/s: 33901
Simulation performance pts/s: 33971
Simulation performance pts/s: 33661
Simulation performance pts/s: 33726
Simulation performance pts/s: 34312
15.000313021 s
Simulation performance pts/s: 34848
Simulation performance pts/s: 34568
Simulation performance pts/s: 34249
Simulation performance pts/s: 34109
Simulation performance pts/s: 33957
Simulation performance pts/s: 34085
Simulation performance pts/s: 34517
Simulation performance pts/s: 34934
Simulation performance pts/s: 34857
Simulation performance pts/s: 34741
Simulation performance pts/s: 35029
Simulation performance pts/s: 35186
Simulation performance pts/s: 34651
Simulation performance pts/s: 34452
14.485670516 s
Dobre ponad 20% wolniej. Dodanie większego heapa wcale nie pomaga. Być może trzeba ten G1 trochę inaczej ręcznie ustawić.
Inaczej, jeżeli GC daje 20% narzut, to ja za taki GC dziękuję. Na CMSie narzut GC nie przekracza 1% (wg. VisualVM).
edytowany 3x, ostatnio: Krolik
0
Jak już mówimy o zmianach w Java 7 to niedawno ukazał się krótki artykuł na ten temat, dolepiam więc linka Tutaj . Całkiem ciekawe, ale co tak na prawde sie zmieniło to zobaczymy przy kodzeniu :D
- Rejestracja:prawie 20 lat
- Ostatnio:około 3 godziny
0
Chodzi chyba o to: http://en.wikipedia.org/wiki/Multitenancy , tzn odpalanie wielu Javowych procesów na jednej instancji JVM. Tak mi się wydaje przynajmniej.
Z tego artykułu: http://tech.pgs-soft.com/2011/08/09/java-8-spoglada-w-chmury/
No to wyjaśnione mniej więcej.
- Rejestracja:prawie 14 lat
- Ostatnio:ponad 13 lat
- Postów:46
0
wiecie może jak podpiąć nowe jdk pod eclipse? Zainstalowałem javke, zaktualizowałem ide, ale jak testowo robię switcha na stringach to podkreśla i erroruje :/
Do czego może przydać się switch na stringach? Jakoś nie mogę wykombinować żadnego sensownego zastosowania.
- Rejestracja:ponad 16 lat
- Ostatnio:23 dni
- Lokalizacja:Polska, Warszawa
- Postów:1058
0
Dokumentacja API Java 7 jest podana jako URL. Jednak jeżeli ktoś ma internet bezprzewodowy z limitem transferu lub po prostu podłe, albo bardzo podłe połączenie i chce mieć tę dokumentację w swoim Eclipse, Netbeans lub po prostu lokalnie w przeglądarce, to podaję niżej najprostszy z możliwych przepis na upichcenie takiego zipa.
Tutaj przy pomocy Netbeans:
- Z katalogu root JDK 7 bierzęmy plik src.zip i wypakowujemy całą jego zawartość do jakiegoś katalogu
- Z tego katalogu usuwamy katalogi com, sunw oraz launcher wraz ze wszystkimi ich podkatalogami.
- Tworzymy w NB nowy projekt "Java Project with Existing Sources". Nazywamy go jakoś sensownie np. Java 7 API.
- Kiedy pojawi się w kreatorze wybór listy katalogów źródłowych oraz testowych, niczego nie dodajemy i kończymy tworzenie projektu.
- We właściwościach utworzonego projektu Build/Compiling wyłączamy opcję "Compile on Save", żeby nie marnować czasu i nie tworzyć ton śmieci na dysku.
- W opcjach Build/Documenting ustawiamy Browser Windows Title najlepiej tak samo jak nazywa się Java API 7 online. Pod "Generate:" zaznaczymy wszystkie lub wybrane rodzaje wygenerowanych plików html.
- W "Additional Javadoc Options" ustawiamy: "-J-Xmx850m". Na Windows XP powinno wystarczyć "-J-Xmx750m" jeżeli ktoś nie ma zbyt wiele pamięci fizycznej.
- Odhaczamy "Preview Generated Javadoc", żeby nie marnować czasu.
- Przechodzimy do pozycji sources, gdzie ustawiamy jeden katalog ze źródłami jako katalog gdzie wcześniej wypakowaliśmy i okroiliśmy src.zip.
- Zatwierdzamy zmianę projektu i zaczynamy robić na drutach, żeby NB spokojnie przemielił wszystkie te źródła w swojej bazie.
- Na projekcie wybieramy z menu kontekstowego "Generate Javadoc", nie przejmujemy się 1,5k ostrzeżeń o nieznanych tagach bo w tym czasie kończymy sweter i nie lampimy się bez potrzeby na okienko Output skoro mamy lepiej widoczną czerwoną lampkę aktywności dysku.
- Kiedy w okienku Output zobaczymy wreszcie zakończenie generowania. Przechodzimy się do katalogu projektu, w nim do katalogu dist, gdzie powinien sobie leżeć śliczny katalog javadoc.
- Katalog ów przenosimy do jakiegoś bezpiecznego miejsca. Odpalamy jakiegoś zipa i pakujemy go do archiwum o treściwej nazwie (na przykład docs.zip dla równowagi z src.zip) z maksymalną kompresją. Archiwum przenosimy do katalogu JDK. Projekt w Netbeans kasujemy wraz z katalogiem z wypreparowanymi źródłami.
Jeżeli do przeglądania (np. kontekstowego) będziemy używać wyłącznie IDE, to katalog javadoc z wygenerowanymi plikami html można sobie skasować (dużo bardzo małych plików) i pozostać tylko przy zipie.
Aby podłączyć taką dokumentację w Netbeans trzeba wejść do menu Tools/Java Platforms, wybrać JDK 1.7, obok zakładkę Javadoc (Classes i Sources są już zazwyczaj poprawnie wypełnione), wybrać "Add Zip/Folder..." i dodać utworzony plik docs.zip.
Po zamknięciu JPM możemy przełączyć notebooka na tryb samolotowy, przejść do swojego wypasionego fotela w klasie business i spokojnie pisać soft aż do przerwy na miskę lub lądowania. ;)
ps. Post powstał ponieważ download dokumentacji API JDK 7 przekierowywał mnie wciąż na wersję online. Obecnie udało mi się wreszcie ściągnąć wygenerowane API.
edytowany 1x, ostatnio: Olamagato
- Rejestracja:prawie 20 lat
- Ostatnio:około 3 godziny
0
Wrzuciłem na przekleja oficjalne API offline do Javy 7, ostatnie które udało mi się zachować na dysku: http://www.przeklej.pl/plik/jdk-7-fcs-bin-b147-apidocs-27-jun-2011-7z-0032a69k8bq4
A tu z oficjalnego serwera:
http://download.oracle.com/otn-pub/java/jdk/7/jdk-7-fcs-bin-b147-apidocs-27_jun_2011.zip :)
ps. ForkJoinPool rządzi...
Dzięki olamagato - potrzebowałem właśnie na laptopa bez internrtu API do javy. Thx. I wibowitowi że o tym pomyślał.
0
Zauważyłem dzisiaj wielką zaletę Javy 7, na mojej maszynie znów działają aplety w Operze i Firefoksie. Otwiera się również konsola Javy w tych przeglądarkach. Aplety w Firefoksie przestały działać począwszy od wersji 3.53, na forum Mozilli spotkałem się z mocnym niedowierzaniem, rady które dostawałem (reinstalacja, nowy profil) nie pomagały. Pomagała instalacja wcześniejszej wersji (3.51).
