KOMPUTERY.CIESZYN.PL

Sebastian Kaliszewski wrote:

Za to PC wyszlo to na dobre -- gdyby IBM zajmowal sie
produkcja oprogramowania na te platforme, to tkwilibysmy
w epoce CP/M. Do przemyslenia podaje ponizsza sytuacje
autentyczna. Jako IBM partner firma kupila od IBM kompilator
dla AIXa na platforme bynajmniej nie PC, wiedzac przy tym,
ze kompilator jest bardzo slaby -- niestety zaden inny tam
nie dziala. Juz w pierwszym tygodniu portingu znalexlismy w
nim kilkanascie bledow, z ktorych 5 zostalo wzorowo
udokumentowanych -- powstaly pelne teksty raportow
z opisem problemu, demonstracja blednego dzialania, wyniki
oczekiwane, propozycje workaroundu itd. Chcielismy
wyslac je do IBM, ale okazalo sie, ze strona do zglaszania
bledow nie pozwala nam na to z powodu niewykupienia
supportu. Poniewaz my nie oczekiwalismy zadnego supportu,
lecz jedynie zapewnienia nam mozliwosci powiadomienia
producenta o usterkach w jego produkcie (za co w sumie to
on powinien nam zaplacic...), najpierw dzwonilismy do
ich autoryzowanego serwisu z prosba o podanie kontaktu,
a poniewaz okazalo sie to nieosiagalne, napisalismy e-maile
do -- jak sie wydawalo -- odpowiednich miejsc. Po
kilku tygodniach (sic!) zadzwonil do mnie czlowiek z IBM
Polska i poinformowal, ze poniewaz nie mamy supportu, to
odmawia przyjecia od nas zgloszen bledow (!!!) i polecil
okresowe pobieranie patchy z ich strony. Niestety nie
powiedzial, co ma byc patchowane, skoro nie wie o
bledach, bo sam odmowil przyjecia zgloszen. :-)
A teraz w ramach konkursu audio-tele proponuje
zgadnac, kto zniknal z listy dostawcow oprogramowania. :-)
    Pozdrawiam
    Piotr Wyderski

Dnia Fri, 20 Oct 2006 12:36:31 +0200, Sebastian Kaliszewski skrobie:

Wiesz, to byly rozwiazania, ktore dzialaly. Ale nic ponad to.

Byly, owszem, co wiecej, byly tanie w sensie osprzetu (np. Z80 nie potrzebowal
dodatkowych kombinacji z pamieciami dynamicznymi). Ale tez nie do konca,
niestety; procesory Intela byly drogie z poczatku, a w czasie popuarnosci
Amigi, za te same pieniadze, co peceta z herkulesem, mozna bylo miec Amige z
narzedziami do profesjonalnej obrobki grafiki. Procesory wowczas Motoroli tez
byly i tansze i wydajniejsze. Ale to sie szybko zmienilo.

Tak - mimo ze byly dostepne za dosc spore pieniadze. Ale to sie szybko
zmienilo; w czasach gdy firmy produkujace Amige dogorywaly po wypuszczeniu
Amigi 1200 i 4000, do tych sprzetow oferowano karty na chipsecie S3,
dwukrotnie wieksze i trzykrotnie drozsze, niz identyczne do peceta.

Owszem. Byla to ryzykowna taktyka; komputery zdobyly popularnosc, ale IBM nie
bardzo chyba wiedzial czym ryzykuje. W tych wlasnie czasach, gdy uzywano Amigi
1200, dowiadywalem sie z prasy, ze IBM juz od lat przynosi wylacznie straty.

Jakie na przyklad?

A owszem, owszem, niestety - glownie dzieki temu menedzerowi z ciastkarni,
ktoremu sie "wyrwalo", ze "IBM nie widzi sensu w braniu udzialu w wojnie o
desktop". Za jakis czas w prasie notatka "IBM wycofuje sie z produkcji OS/2".
I dalej poszlo z gorki (na sam dol). Mimo ze, jak slyszalem, byl to system
wielokrotnie lepszy od owczesnego Windows 95.
No i poza tym nikt inny nie probowal konkurowac w "wojnie o desktop". Zreszta
ta wojna tez nie byla do konca fair, jak wyczytalem w Wikipedii:
Wedlug doniesien CNET [2] miedzy firmami IBM i Microsoft doszlo do potajemnej
transakcji wartosci 800 milionow dolarow, ktora miala na celu "ustapienie
drogi" produktowi Microsoftu. OS/2 bedac znacznie lepszym systemem operacyjnym
przegral w nierownej walce.
[2] http://news.com.com/2100-1014_3-5771535.html

Nie do konca. Czesto przy zakupie oszczedza sie na researchach w ten sposob,
ze bierze sie to, co juz jest popularne. Jesli jest jeszcze zadowalajace, to
ci, ktorzy decyduja o zakupie, niczego juz wiecej nie potrzebuja.
A ja wlasnie mam okazje sie przyjrzec jednemu projektowi aplikacji webowej w
Javie i caly czas mam wrazenie, ze naprawde, daloby sie to napisac krocej,
zwiexlej, czytelniej, ze znacznie mniejsza iloscia kodu. Takich kwiatkow jak
na thedailywtf.com to moglbym tam znalesc na peczki. No ale co z tego. Mozna
na to narzekac, ale pewnie lepszych nie ma. Jedyne rozwiazanie, ktore wybija
sie przez minimalna ilosc wymaganej pracy (i minimalna ilosc narzedzi) to Wt.
Ale Wt niestety jest napisane w bardzo paskudnym jezyku C++, wiec ludzie tego
nie uzyja, bo wola mieszanie Javy z PHP i reczne dlubanie w plikach XML.

Nie jest mierzalny. Chocby dlatego, ze tak sie przypadkiem sklada, ze sam
jezyk odgrywa w tym wszystkim niewielka role. W C++ jest wiele mechanizmow,
ktore potrafia zwiekszac bezpieczenstwo kodu. Problemem nie jest ich brak,
tylko ich niestosowanie. A dlaczego nikt tego nie stosuje. No coz, dobre
pytanie.
Zdecydowanie uwazam, ze w C++ za malo rzeczy podaje sie ludziom na tacy.

Java jako "srodowisko programowania, system bezpieczenstwa, platforma, zestaw
bibliotek" - tu sie zgodze. Jako jezyk - niestety sie nie zgodze.

Jest jeszcze tego znacznie wiecej, ale owszem, wlasnie to mialem na mysli.

Te ostatnie to pominmy, bo po pierwsze, UML-a trzeba jednak traktowac troche
mniej powaznie, niz wiekszosc ludzi probuje, a po drugie, jesli chodzi o
narzedzia do UML-a, to z moich obserwacji nie zauwazylem, zeby jakiekolwiek
narzedzie UML-owe generujace kod nie obslugiwalo C++.
Co do Eclipse i NetBeans, to obejrzalem na razie tylko ten pierwszy, musze
przyznac jak na razie jedyny produkt Javowy, ktory zrobil na mnie
oszalamiajace wrazenie. Ale jako IDE jest dla mnie troche marne, bo mialem
powazne problemy z dostosowaniem go do mojego projektu (inna sprawa, ze akurat
robilem to w CDT, o ktorym slyszalem, ze nie jest wysokich lotow).

Ogolnej wizji, tzn. czego na przyklad? Oczywiscie, ze wiele propozycji wyglada
na wyrywkowe, bo potrzebne sa po prostu takie wlasnie wyrywkowe poprawki na
najbardziej uciazliwe problemy. Natomiast ogolny plan bedzie mozna zrobic
dopiero wtedy, gdy bedziemy wiedzieli, jakie opracowane rozwiazania mamy do
dyspozycji.

ta propozycje widzialem chyba juz dwa lata temu.

Nie wiem, czemu tyle z tym zwlekali. Moim zdaniem jest to wzorcowy przyklad
dobrze zaprojektowanego ficzera, posiadajacego na dodatek referencyjna
implementacje (ktora osobiscie pomagalem testowac). Nie mozna przeciez
oczekiwac, ze opracowywanie ficzerow pojdzie od razu szybko i sprawnie; lepiej
zeby sie to lekko przeciagnelo, niz zeby mial wejsc do standardu kulawy
ficzer.

Podobno maja byc, ale na razie zapomnialem linka (mam u siebie na komputerze,
ale poszedl do serwisu, poza tym jestem teraz w okregu Dallasowskim :).

To jest kwestia wsparcia platformy, a nie samego jezyka. Co do tego juz
mowilem, to jest prawda - C++ wymaga jeszcze duzo pracy, zeby te kwestie
doprowadzic do porzadku.

To niby Java ma mniej dziurawy system typow? Niby w ktorym miejscu?
Tylko nie wyjezdzaj mi tu z reinterpret_cast, bo cie wysmieje.

Fakt, przydaloby sie zmniejszyc ilosc tych UB i komitet nad tym pracuje.
Oczywiscie czesci z nich nie uda sie zlikwidowac nie narazajac sie na
dodatkowe koszty, dlatego tez bedzie istnialo cos takiego jak
"conditionally-supported behavior", czyli inaczej mowiac, zwalenie problemu na
implmentacje i platforme.

Ale jak na razie tylko Java go wyprzedza.

Rozmach w uzyciu wzorcow w Boost zdaje sie niestety przeczyc twoim teoriom.
Fakt, ze maja tam wiele konstrukcji warunkowych, ale nie az tyle przede
wszystkim nie
... wiecej »

Krzysiek Kowaliczek wrote:

To nie powinno dziwic, narzut zwiazany z przedrostkiem
lock jest gigantyczny. Przedrostek ten implikuje m.in. pelna
bariere pamieci (L-L, L-S, S-L, S-S), co na procesorze
mogacym miec wiele operacji na pamieci w roznym stadium
wykonania po prostu musi byc drogie. Niestety IA-32 brakuje
instrukcji atomowych bez semantyki bariery. PowerPC
i Sparc rozdzielaja zagadnienia atomowosci i spojnosci
pamieci, wiec takie liczniki na nich sa znacznie wydajniejsze.
Sa sposoby, by nie uzywac nawet instrukcji atomowych do
synchronizacji (a przynajmniej robic to rzadko), ale opieraja
sie one na dokladnej znajomosci modelu pamieci danej maszyny
(np. TSO na Sparcu), wiec sa skrajnie nieprzenosne (nie dzialaja
nawet na tym samym procesorze przy innym modelu spojnosci,
np. PSO lub RMO), za to sa tez skrajnie szybkie. Do C++
sie zasadniczo nie nadaja (bo nie mozna wymusic zachowania
przez kompilator kolejnosci instrukcji), ale do maszyn wirtualnych
nadaja sie swietnie. Stad mozliwosc pobicia wydajnosci kodu
rownoleglego napisanego w C++ przez kod np. w Javie jest
mozliwa, jesli sie tego rodzaju sztuczki upowszechnia. No chyba,
ze do C++ zostanie dodane slowo kluczowe wskazujace granice
optymalizacji blokow -- wowczas bedzie 1:1. Ale poki C++ nie
ma pojecia o watkach, zagadnienie jest bezprzedmiotowe. :-P

Coz, jesli zamierza sie pisac wydajne programy rownolegle,
to rezygnacja z systemowych funkcji synchronizujacych jest
jedna z pierwszych decyzji do podjecia. :-)

A na ilu procesorach bedziesz uruchamial testy? Bo
naj jednym to nie ma sensu, a na 4 nawet dzielony
spinlock mocno ogranicza skalowalnosc. A tak wlasnie
byl zrobiny licznik referencji w std::stringu w GCC
na Solaris. Po kilku recznych poprawkach i wstawkach
asemblerowych dajacych dostep do cas/casx zaczelo
sie jednak skalowac liniowo.

Co nie powinno dziwic -- trzymanie licznika referencji w osobnym
bloku pamieci to sredni pomysl. Jestem zdania, ze jesli uzywa sie
licznika referencji, to w gre wchodzi tylko zawarcie go w obiekcie
wskazywanym.
    Pozdrawiam
    Piotr Wyderski

Krzysiek Kowaliczek wrote:

Ano niestety, nie da sie podstawic wlasnego alokatora.

Tego tez sie nie da zmienic.

Hm, a to jest: deleters.
    Pozdrawiam
    Piotr Wyderski

Piotr Wyderski wrote:

Moglbys podac jakie informacje dotyczace tego. Zagadnienia
niskopoziomowe bardzo mnie interesuja ( do tej pory nie wyszedlem poza
recznie rzezbionego spinlock :) )

Czy __preserve_ordering o ktorym kiedys wspominales zalatwilo by sprawe?

To jest chyba zart :)?

Wlasnie - niestety wszystkie suny oraz linuksy maja po 1 procku :(.
Odzwe byl slaby wiec testy z linuksa gdzies zawieruszylem, ale z tego co
pamietam to mutex z pthread byl ok 1.8 wolniejszy niz wersja z
instrukcjami atomowymi.
Wiem, ze takich testow nie mozna wyciagac pochopnych wnioskow ( chociaz
przekonalem sie, aby nie trzymac licznika referencji na zewnatrz obiektu
). Mozna uniknac nadmiernego kopiowania "sprytnych wskaznikow" ( tj.
wymusic na uzytkownikach, aby nie pobierali kopii "spryntego wskaznika"
  nadaremno ), np: dla kolekcji przygotowac iteratory transformujace,
zwracajace jako wynik zwykly wskaznik.
Pozdrawiam
KK

Sebastian Kaliszewski wrote:

Java bez przeciazania operatorow, bez deterministycznej destrukcji i bez
tak fundamentalnych rzeczy jak odroznienie czy funkcja modyfikuje swoj
argument czy nie, bez kontroli nad zuzyciem pamieci dynamicznej, etc.
Jesli chodzi o system typow, to wiem, jak naprawic ten w C++. W Javie
wiem, ze sie go naprawic w ogole nie da.
Chyba mamy rozne punkty widzenia.

W kazdym porzadnym jezyku sa narzedzia z kategorii "w razie potrzeby
zbic szybke". :-)

Styknie na podstawowe potrzeby - zwlaszcza, ze mozna go stosowac w
roznych stopniach odwolan posrednich.
Brak jakiegokolwiek mechanizmu jest zdecydowanie ubozszy.

Podobnie jak w wiekszosci jakich jezykow?
Odrebne specyfikacje interfejsow sa w *kazdym* jezyku, ktory byl od
poczatku projektowany do zastosowan w zlozonych systemach.

Blad. Przy braku const (albo specyfikatorow in/out/inout) kontrakt na
niezmiennosc argumentu musi byc zapisany w pierwszych *oraz* *ostatnich*
wierszach. Ups, nie tylko ostatnich - kluczowe sa tu wszystkie punkty
wyjscia z funkcji (return tu i owdzie), rowniez te niejawne (wyjatki).
Daloby sie to uproscic majac RAII, ale gdzie RAII w Javie.
Gdzie ta wychwalana przez Ciebie inzynieria oprogramowania?
No i, jak to sie mowi w inzynierii oprogramowania, kontrakt powinien byc
od implementacji oddzielony. Ale do tego niestety potrzebny jest jezyk,
ktory byl od poczatku w ta strone projektowany.

Bezkrytycznych? Nie znam takich.
Natomiast znam ludzi, ktorzy namietnie bluzgaja na C++, prorokujac jego
rychle zejscie, jednoczesnie aktywnie dzialajac na rzecz jego utrwalenia
i umocnienia.

Nie. Firmy produkujace te wlasnie procesory targetuja rynek, na ktorym
nikt nie pisze programow bezposrednio na sprzet. Pisze sie raczej
programy chodzace pod kontrola jakiegos systemu operacyjnego - wtedy
kluczowym zagadnieniem jest to, czy jezyk umozliwia wykorzystanie API
tego systemu. Moze to byc albo wykorzystanie bezposrednie (wywolania
funkcji), albo posrednie (ukryte w runtime tego jezyka), ale tak czy
inaczej ograniczeniem jest to, jak jezyk korzysta z API systemu.
Paradoksalnie, w najlepszej sytuacji sa tutaj te jezyki, ktore sa mniej
lub bardziej natywne wzgledem danego systemu - czyli te same, ktore
obecnie nie maja formalnego wsparcia dla wspolbieznosci. Jaja, co?

Ewentualny powrot Ady nie bedzie mial zadnego zwiazku z jej ficzerami do
wspolbieznosci - z powyzszych powodow. Ada ma te ficzery zdefiniowane na
bardzo wysokim poziomie abstrakcji, co ma ogromna zalete w dziedzinie
przenosnosci: zadnego cudowania z bibliotekami, po prostu dziala. Tu
nalezy sie respekt i czapki z glow. Ale to nie jest kluczowe w
kontekscie wielordzeniowej rewolucji. Niezaleznie od tego, czy rdzeni
bedzie dwa czy pincet, kluczem do ich wykorzystania jest API systemu
operacyjnego. Ada oczywiscie umozliwia bezposrednie (przez linkowanie -
to nie Java i zadnego badziewia w stylu JNI tam nie potrzeba) wolanie
takich funkcji, ale ten temat sie mocno komplikuje gdy w okolicy
pojawiaja sie wskaxniki do danych programu albo funkcje callback.
Tak czy inaczej, tradycyjnie pojmowana kultura Ady raczej wyklucza
wywolania do API systemu jesli jezyk sam cos wspiera, wiec nikt tak
pisac nie bedzie. Ludzie beda uzywac ficzerow jezyka zamiast API systemu
- a to potrafi kosztowac nawet dwa rzedy wielkosci w wydajnosci. Zmierzylem.

Natomiast swiat Javy jak jeden maz przesiadl sie na Jave 1.5, tak?
Niestety, nie.

Problem w tym, ze nawet takie badziewie jak MSVC6.0 ma tak podstawowe
konstrukcje jak enumy. Generyczny kontener tez da sie napisac.
W porownaniu do tego Java 1.4 to kamien lupany. Codziennie pracuje z
czlowiekiem, ktory tego uzywa (piszemy dwie strony tego samego systemu)
i pomagajac mu odczuwam cos na ksztalt klaustrofobii. :-)
--
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

Maciej Sobczak napisal(a):
- Ukryj cytowany tekst -- Pokaz cytowany tekst ->> Nota bene, Ada ma wspolbieznosc rozwiazana porzadnie -- nie mozna

A tu pozwole sie nie zgodzic, bo jak API bedzie pozwalalo na takie
rzeczy to pewnie kompilatory Ady (i inne tez) beda pewnie o tym
wiedzialy i nawet te natywne watki Ady beda odpowiednio tlumaczone na
zabawe z API rdzeni, przeciez skompilowany program nic poza API
wykorzystac nie moze. Nie mozna w OSie inaczej utworzyc watkow jak tylko
przez API systemu.
A mozna wiedziec jak testowales te wywolania API i ficzery jezyka?
Kiedys jak testowalem rozne rzeczy z wywolywaniem roznych rzeczy
zewnetrznych bibliotek niepisanych w Adzie, to roznica wynikala glownie
ze wzgledu na sprawdzanie przez Ade przepelnienia tablic, zmiennych itp.
Po wylaczeniu tego wszystkiego program znacznie przyspieszal. W
zewnetrznych bibliotekach nie bylo zadnego sprawdzania tego typu rzeczy,
  wiec dzialaly nieco szybciej.

Sektor van Skijlen wrote:

Ale juz dysk twardy MFM do tego PC-ta byl tanszy niz do Amigi (590 kosztowal
chore pieniadze i byl ciagle ten sam, podczas gdy wielkosc dyskow do PC
"rosla").
Do Amigi istotnie byly profesjonalne i tanie sprzetowo-programowe systemy do
obrobki Video na zywo, byly tez Raytracery i inne rzeczy "filmowo
zorientowane" -- i tez w tych okolicach profesjonalne oprogramowanie sie
konczylo.
Amiga byla kompueterem na rynek domowy oraz dodatkowo na rynek
profesjonalnej obrobki video (bardzo waski). PC byl kompuetrem na rynek
biurowy -- a tam tak jak w tedy tak i dzis jest ok 80% ruchu (i bodaj
jeszcze wiecej procentowo kasy).

Ta choroba zaczela sie juz duzo wczesniej. Vide ow A590...
Pomysl, by zrobic komputer osobisty w postaci blaszanego pudla gdzie w
srodku jest kilka gniazd na karty rozszerzen byl strzalem w 10. Makowki,
Amigowcy, Atarowcy i reszta sie z tego najpierw podsmiewali, by wkrotce
zaczac to (dosc nieudolnie) nasladowac.
Rownolegle z Amiga 1200 mialem PC 486 -- do niego byla juz karta graficzna z
Truecolor w 640x480 i z 1152x856 w 256 kolorach. To juz bylo lepiej niz
rzeczona Amiga. Procesor w tym PC byl tez szybszy niz to co sie dalo do tej
Amigi wcisnac. Potem jak PC dorobil sie 1GB dysku to stara 200MB poszlo do
Amigi, potem PC przestal juz byc 486 i w tym miejscu Amiga juz nie miala
szans...

W tych czasach to "wielki zjazd" juz sie odbyl.
Nota bene, sama katastrofa poszla cholernie szybko (biorac pod uwage
wielkosc "ofiary"). To bylo w czasach startu 386. IBM zamiast rozszerzyc AT,
postanowil zamknac architekture PC, robiac PS-2 (z magistrala microchannel).
  Rownoelegle byli tak pewni swojego, ze chcieli jesze wydoic szybsze
(16MHz) 286 i zwlekali z wprowadzeniem modeli 386.
W tym czasie nowowyrosle (wprost z rewolucji PC) firmy takie jak Compaq,
Gatweay czy juz nie tak mlody ale szybko rosnacy HP przyjely strategie
optymalna -- rozszerzono AT wprost do prockow 386 i nikt nie zlamal
kompatybilnosci. Dodatkowo dogadali sie szybko w kwestii szybszej szyny
(VESA -- choc to bylo nieco poxniej). Wypuscili 386 wczesniej niz IBM i
przejeli inicjatywe. Po doslownie kilku miesiacach (mniej niz 10) bylo juz
po wszystkim. IBM przynosil straty, a silna grupa nowych mlodych gwaltownie
rosla. Przy okazji pare firm, wsrod nich Commoodore, ktore przegapily
rewolucje (obalenie hegemonii IBM) wyladowalo na prostej sciezce do bankructwa.
IBM byl za duzy, zeby zbankrutowac -- ale kiedy stratry poszly w miliardy
musieli sie zreorganizowac. A kiedy kurzawa opadla byli juz jedna z wielu
firm a nie kolosem o rzad wielkosci wiekszym od konkurencji.
IBM znalazl swoja nisze w tym co robi najlepiej -- w duzych systemach
komputerowym i w sprzedawaniu serwisow a nie samego sprzetu. Sprzet jest w
zasadzie tylko dodatkiem.

* kaszane memcpy, strcpy itd. W 1995 roku to byla zasada dzialania w C++.
* dawala mimo wszytsko dzialajacy i wlaczony do standardu jezyka GUI
- Ukryj cytowany tekst -- Pokaz cytowany tekst ->>>>>Glosy rzeczywistych uzytkownikow sie nie licza, bo

To co jest popularne jest tez zwykle lepiej sprawdzone. Glupio jest wdepnac
w jakis powazny bug w zewnetrznym oprogramowaniu.

Wt jest tez malo popularne i przez to podejrzane. Ale sa tez chwalone
rozwiazania dla innych jezykow, np Ruby on Rails (nie znam, tylko duzo
dobrego slyszalem).

Odpowiedx jest dosc oczywista. W C++ bardzo czesto "the obvous way" jest
rownolegle "error prone & dangerous way".

Co gorsza na tacy podaje sie trucizny.

Jak sam napisales: jezyk odgrywa w tym wszystkim niewielka role.
Poza tym Java wyprzedza C++ w jednej ale bardzo istotnej rzeczy --
praktycznym braku Undefined Behaviour a takze Implementation Specific Behaviour.

Gorzej jest w druga strone...
- Ukryj cytowany tekst -- Pokaz cytowany tekst -> Co do Eclipse i NetBeans, to obejrzalem na razie tylko ten pierwszy, musze

Wczesnie wytyczamy cele, np. Jezyk ma miec sanadrowe GUI i obsluge sieci;
semantyke watkow i bibliotek dzielonych. Poniewaz nie kazdy potrzebuje GUI
lub sieci lub tez sensownej obslugi plikow, to planujemy podzial biblioteki
na core i moduly i planujemy jakies drzewo zaleznosci.
Tym celom podporzadkowuje sie prace komitetu i rozwiazania sprzyjajace tym
celom maja priorytet (tzn. np nmad niemi obraduje sie w pierwszej kolejnosci).
- Ukryj cytowany tekst -- Pokaz cytowany tekst -> Oczywiscie, ze wiele propozycji wyglada


... wiecej »