AK <n...@n...com> wrote:
> U?ytkownik "Waldek Hebisch" <h...@m...uni.wroc.pl> napisa?:
>
> >> > Odry 1300 to i licencja od brytyjczykow.
> >>
> >> Bzdury Wasc pleciesz.
> >> To tez polska konstrukcja.
> >> Nie calkiem czysto polska, ale tez zadna licencja.
> >> Zaprojektowana i wykonana od 0 przez Polske/Polakow (z duuuuzym dodatkiem
> >> pewnego Greka:))
> >
> > Sprzet zrobiony przez Polakow, ale oprogamowanie ktore tak chwalisz
> > od Brytyjczykow.
> >
> > Na skale krajowa to bylo osiagniecie. Ale pod wzgledem technologiczym
> > jak Odry wchodzily do produkcji seryjnej to byly jakies 5-7 lat
> > do tylu w stusunku do zachodu.
>
> Chyba jednak niedokladnie przeczytalem o rozwiazaniach technicznych
> u Urbanka (mikroprogramowani itp).

W IBM mikroprogamowanie bylo w seryjnej produkcji od 1965. Wedlug
Urbanka seryjna producja 1204 to 1968, 1304 to chyba 1970,
a 1305 to 1973 -- w 1968 mikroprogramowanie bylo standartowa
technika.

> O wydajnosci w stosunku do ICLa tez

To ze Odra byla szybsza od ICL 1904 znaczy niewiele. Byly
wtedy duzo szybsze maszyny. Technologicznie pamiec 6 us
to nic specjalnego. Kolo 1970 roku w zachodnich mainfame
2 us to byla "powolna" pamiec, a szybka to 1us.
W 1973 gdy Odra 1305 uzywala TTL-e SSI na zachodzie standard to
bylo MSI.

> > Urbanek pisze ze Odra to duza maszyna i porownuje mozliwosci obliczeniowe
> > Odry 1305 do IBM370/145. Tyle ze 145 to pogranicze maszyn malych i srednich.
> > IBM mial znacznie wieksze maszyny. Ruscy mieli BESM-6.
>
> Pracowalem na Odrze1325 i 1305 i RIADdzie 370
> Poza wirtualizacja OSsow na 370 nei widzialem _zadnej przewagi_ 370
> a raczej same disadvantages.
> O jakosci sprzetu RIADowskiego moglbym, tu kilka legend (prawdziwych:)
> przytoczyc :). Odra to byl kosmos neizawodnosci w stosunku do RIADow
> (no moze poza slawetnymi stacjamisc tasm PT czy czytnikiem karpo perf,
> ale to drobnostki).

Duze RIADy ponoc byly duzo szybsze.

>
> > > Co do oprogramowania, to bylo w zasadzie nierozwojwe.
> > Tzn. podstawowe adresy Odry to 15 bitow i to w 1973 bylo
> > malo jak na mainframe.
> > Bylo rozszerzenie do 22 bitow, ale juz to wprowadzalo komplikacje.
> > 24 bitowe rejestry oznaczaly ze wydluzenie adresu powyzej 24 bitow
> > wiazalo by sie z duzym problemem.
>
> Chyba nie czytales dokladnie Urbanka.
> Mowimy o Odrze 1305.

Z tego co wiem (i zgadza sie z tym co pisze Urbanek) rejestry
Odry byly 24 bitowe. Urbanek nie pisze o formacie rozkazow,
ale kiedys go sobie ogladalem: normalne rozkazy mialy 15
bitow na adres. Nie pamietam detali, ale tryb 22 bitowy
wymagal dodatkowych kombinacji.

> > Mysle ze najlepszym podsumowaniem jest tu koniec u Urbanka:
> > jak zniknely ogranicznia COCOM to Odra w Polsce stacila
> > wszelki sens ekonomiczny.
>
> Ograniczenia COCOM zniknely dopiero w dobie PCtow
> czyli po 1989 (sam pierwsze kompilatory TP/TC czy MS Fortran
> czy Zortech C++ na AT w 1987 jeszcze zyczajnie "kradlem od ruskich")
> a Odra to lata 70te.

Rzecz w tym ze zachod nas wyprzedzil. I czasie produkcji Odry
dystans rosl (procesory bit-slice to 1975, SKOK ktory je
uzywal to 1989).

--
Waldek Hebisch
h...@m...uni.wroc.pl

do góry

Użytkownik "Waldek Hebisch" <a...@m...uni.wroc.pl> napisał:

>> O wydajnosci w stosunku do ICLa tez
>
> To ze Odra byla szybsza od ICL 1904 znaczy niewiele.

Nie no jaase . To pikus, a "zakunkorowalismy" skutecznie z Angolami :)

>> O jakosci sprzetu RIADowskiego moglbym, tu kilka legend (prawdziwych:)
>> przytoczyc :). Odra to byl kosmos neizawodnosci w stosunku do RIADow
>> (no moze poza slawetnymi stacjamisc tasm PT czy czytnikiem karpo perf,
>> ale to drobnostki).
>
> Duze RIADy ponoc byly duzo szybsze.

Taa. bys moze, tylko ciezko to bylo zauwazyc, bo rzadko byly w stanie
"rozwinac" ta swa szybkosc.

Opowiastka1:
for i in range(1,52, step+co tydzien/2tygodnie):
Np rok 1987. WSK Rzeszow. Miejsce : tzw ETO
"Bohater": RIAD - oczywiscie siadl na amen, a na nim cala baza technologiczna,
place, akord itp... "drobnostki"
Przyjezdza laskawie serwis (jeden na cala pld Polske z Krakowa)
Od bramy do ETO ok 400m.
Wchodza. Zgodnie z zaleceniami "z gory" natychmastowy telefon do
wartowniko w na bramie - "nie wypuszczac ICH na zewnetrz pod byle pretekstem!,
dopiero po telefonie "od nas mozna."
Po wielu probach/2godzinach naprawili procesor. Przy "naszych" swiadkach
jednostka centralna zadzialala (nigdy nie wierz serwisowi RIADA na slowo :).
System wystartowal. Szybko wyszli (bo meili jeszcze ze 2 "szybkei" RIADY w okolicy
wskrzesic. "U nas" szybkie proby podstawowe na calego testy: wew. i zew. itp
Oczywiscie po 15 min RIAD znow padl na dobre - od razu tel na brame.
Sa jeszcze! - bo wartownicy nie spieszylo sie z kontrola/przepustkami :)
- zawrocili, przyszli wkur..ni jak Krakusy, ale "my" tez: Ma dzialac albo bedziecie
tu k... nocowac!
Po godzinie jakos dzialalo a wartownicy schowali bron :)

Opowiastka2:
"Ruskie" ciagle wyprzedzaly IBM z wydawaniem "releases" OSa RIADowego.
Montiowali zawsze z numerkiem wiekszym niz IBM.
Dlaczego ? Ano dlatego ze aby RIADowstwo zadzialalo jakos na "wybitnym" sprzecie
bulgarsko (dyski) wegierskim (a i naszym nie lepszym) musieli nie tylko w "jadrze"
orginalnego (czytaj ukradzionego) OSsa powstawiac jakies "sleep(3000)" coby "sprzęt
nadążał"...
Nie musze dodawac ze ten ruski OS byl w 100% zerzniety z IBM360/370
bez jakichkolwiek "umow licencyjnych".
Dlatego RIAD "raczej" na zachod sie nie sprzedawal :)

Mozna by tak dlugo...

Do czytajacych nalezy ocena czy/na ile przebarwiam/podbarwiam
ichniejsza rzeczywistosc "technologiczna" maszyn "jednolitego systemu"
RIAD.

PS: No ale po co to wypisuję ? Przeciez wiadomo ze Odra to syf, a Urbanek
lze co drugie slowo. Prawda ? No bo przeciez polskie niegdy nie moglo
byc dobre . Prawda mlodziezy ?

AK


---
Ta wiadomość została sprawdzona na obecność wirusów przez oprogramowanie antywirusowe
Avast.
https://www.avast.com/antivirus

do góry

On 2015-09-14 08:56, Tomasz Kaczanowski wrote:
> to spokojnie powinno dać sobie radę i dopóki nie wyremontuje się linii,
> to zmiana sprzętu może być nieopłacalna, skoro działa...

Sprzęt działa czasem tylko dzieki szczęsciu. Bo bez względu na jego
jakość, operator mógł sobie zejśc na zawał a innych nie ma. O tym jest
spory kawał wątku i jestem zmeczony powtarzaniem dlaczego legacy systems
są niebezpieczne *nawet* jesli działają.

do góry

AK <n...@n...com> wrote:
> U?ytkownik "Waldek Hebisch" <h...@m...uni.wroc.pl> napisa?:
>
> >> Nie wierze. C nie nadaje sie do weryfikacji formalnej poprawnosci programow
> >> w nim pisanych (chyba ze jest to baaardzo okrojone C - i to o wiele bardziej niz
Misra C),
> >> a jadro to jaderko na przyslowiowych "kilku kartkach" i "specjalnie pisane" pod
werfyfikacj?.
> >>
> >> W zwyklym C/C++ formalna weryfikacja pooprawnosci to zwykla
> >> uluda (i taka na zawsze zostanie).
> >>
> >
> > Mikrojado L4 ma kolo 8000 lini kodu.
>
> No to naprawde... Potega !
> PS: "My ze szwagrem" zweryfikujemy takie cus w miesiac za 34PLN/h :)
>
> > ZCW weryfikacja obemuje np. sprawdzenie ze nie ma przepelnien buforow.
>
> a wystarczylo uzyc jezyka w ktorym np. przepelnienie buforow nie wystepuje/
> nie grozi kolapsem (ehh ta "wysokopoziomowosc" C /C++:)

No, np. w Adzie typowe wymaganie w takich sytemach to brak
wyjatkow. I problem wraca.

> > Co do C to jest rozpracowana odpowiednia logika i ponoc teraz
> > nie sprawia wiecej problemow niz inne jezyki.
>
> Jaasne. Wystaczy po prostu zrezygnowac z pointerow :)
>
> PS: Nie moge "wyjsc z podziwu" dlaczego do napisania tak malych przeciez rzeczy
> jak to mikrojadro nie uzyc chocby Ady , ktora z zalozenia o niebo lepiej
> nadaje sie do weryfikacji poprawnosci formalnej programow.
> Z C/C++ to najpierw stwarza sie problemy (poprzez samo jego uzycie) a pozniej
> bohatersko i wielkim nakladem sil sie rozwiazuje (typowe slodzienie herbaty
> przez mieszanie w lewo). Poza tym o ile jeszzce pamietam to glowna materia
> formalnej weryfikacji poprawnosci priogramow to nie wylapywanie jakiegos
> przepelnienia bufora, ale sprawdzanie zgodnosci "flow" kodu programu
> z "flow" projektu (badanie zgodnosci kodu z zalozeniami logicznymi).

Wez sobie przeczytaj:

https://sel4.systems/FAQ/proof.pml

Nie ma co dyskutowac dlaczego tworcy L4 wybrali C. ZTCW to jest
pierwszy przyklad w jakimkolwiek jezyku gdzie udalo sie pokazac
tak wiele. Zalozenie ze Ada jest lepsza do weryfikacji jest
naturalne. Ale narzedzia do Ady (SPARK) na razie daja mniej.

--
Waldek Hebisch
h...@m...uni.wroc.pl

do góry

AK wrote:

> Użytkownik "Roman W" <b...@g...pl> napisał:
>
>> Pod warunkiem, że się nie używa dat. W Pythonie sa co najmniej trzy klasy
>> do dat: datetime.datetime, numpy.datetime64 i pandas.Timestamp. Aha, i
>> geniusze którzy projektowali datetime zapomnieli, że ktoś może mieć
>> timestamps z nanosekundami " bo przecież żaden zegar w pececie nie ma
>> takiej rozdzielczości " :)
>>
>> RW
>
> W Pythonie standardem jest datetime. Nie wprowadzaj falszu.

Ktory sie srednio nadaje do obrobki np. szeregow czasowych. Te inne typy
ktore podalem sa bardziej wydajne.

datetime w dodatku ma malo wygodne wsparcie dla stref czasowych w porownaniu
z typami z pandas.

> Oczywiscie nic nie zabrania innym pakietom miec swoje typy danych
> (w czesci to zaczlosci sprzed datetime).
> Co do nanoseconds:
> "
> time.time()
> Return the time in seconds since the epoch as a floating point number.
> Note that even though the time is always returned as a floating point
> number, not all systems provide time with a better precision than 1
> second. "
> time.time() uzywa:
> GetSystemTimeAsFileTime()
> https://msdn.microsoft.com/en-us/library/windows/des
ktop/ms724397(v=vs.85).aspx
> lub clock_gettime(CLOCK_REALTIME)
>
http://pubs.opengroup.org/onlinepubs/9699919799/func
tions/clock_getres.html
> lub gettimeofday()
> http://man7.org/linux/man-pages/man2/gettimeofday.2.
html
> w zaleznosci od mozliwosci platformy platformy/OSa
> Jesli wpaniałe C i wspanialy OS w swym API dostarcza rozdzielczosc
> nanosekundową, to bedziesz jak w rezultacie time.time() mial.

A jak mam dane z zewnetrznego systemu? Np. z akceleratora czastek albo tzw.
spoolera na gieldzie.

> Gdy masz/chcesz uzyc jakies inne/swoje/specyficzne (real?)"timerowe" API w
> C to nie ma najmniejszego problemu uzyc tego poprzez ctypes w 2-3
> linijkach: np:
> from ctypes import libc
> print libc.time
> lub np:
> from ctypes import windll
> print windll.kernel32.GetSystemTimeAsFileTime
> lub np:
> from ctypes import windll
> dll = CDLL("moja_dllka.dll")
> print dll.moja_funkcja

Czyli nie jest to przenaszalne. pandas.Timestamp jest.

RW

do góry

On Mon, 14 Sep 2015 14:05:12 +0200, AK wrote:

>> [...] więc
>> zrobiono i robi się dużo, by młodzieży wydawało się, że rozmowa z kolegą
>> przez smartfona na fejsie jest wartościowsza niż rozmowa w cztery oczy.
>
> Trafienie w sedno.

A tu trafiłem artykuł dość chyba dobrze opisujący fundamenty tego zjawiska
od strony psychologii i socjologii:

http://tinyurl.com/n9tdaq3

i pelny adres:

http://serwisy.gazetaprawna.pl/edukacja/artykuly/892
103,nasze-dzieci-to-najwieksze-pierdoly-na-swiecie-h
odujemy-zombi-ktore-nie-wiedza-kim-sa.html

--
howgh
szemrany
"Trzeba z żywymi naprzód iść, po życie sięgać nowe,
a nie w uwiędłych laurów liść z uporem stroić głowę"

do góry

Użytkownik "RW" <b...@g...pl> napisał:

>> W Pythonie standardem jest datetime. Nie wprowadzaj falszu.
>
> Ktory sie srednio nadaje do obrobki np. szeregow czasowych. Te inne typy
> ktore podalem sa bardziej wydajne.

datetime nie nadaje sie rowniez do obliczenia calek eliptycznych.

> datetime w dodatku ma malo wygodne wsparcie dla stref czasowych w porownaniu
> z typami z pandas.

tz z datetime dziala wystarczajaco. (Przynajmniej "u mnie" :)
Czepialstwo kolejne.

>> Jesli wpaniałe C i wspanialy OS w swym API dostarcza rozdzielczosc
>> nanosekundową, to bedziesz jak w rezultacie time.time() mial.
>
> A jak mam dane z zewnetrznego systemu? Np. z akceleratora czastek albo tzw.
> spoolera na gieldzie.

To se to oprogramuj.
Skad niby Python albo os ma wiedziec o tym akceleratorze automatycznie ?

>> from ctypes import windll
>> dll = CDLL("moja_dllka.dll")
>> print dll.moja_funkcja
>
> Czyli nie jest to przenaszalne. pandas.Timestamp jest.

Znow zwykle "zdziwianie".
Tak jak pisalem: masz time.time() ktore jest przenaszalne jesli os dostarcza
w ogole rozdzielczosc nanosekundowa, a to wciaz rzadkosc.

PS: Pythonowe time.time() jest o wiele bardziej portable niz C-owe time()/gettime()

AK


---
Ta wiadomość została sprawdzona na obecność wirusów przez oprogramowanie antywirusowe
Avast.
https://www.avast.com/antivirus

do góry

Użytkownik "szemrany" <s...@o...off> napisał:

>> Trafienie w sedno.
>
> A tu trafiłem artykuł dość chyba dobrze opisujący fundamenty tego zjawiska
> od strony psychologii i socjologii:
>
> http://tinyurl.com/n9tdaq3
>
> i pelny adres:
>
> http://serwisy.gazetaprawna.pl/edukacja/artykuly/892
103,nasze-dzieci-to-najwieksze-pierdoly-na-swiecie-h
odujemy-zombi-ktore-nie-wiedza-kim-sa.html

Czytalem juz chyba z tydzien temu i.. cholernie smutno mi sie zrobilo (artykuł jest
zwyczajnie
dołujący) bo prawdziwe i z"zycia wziete" :(

Co do int set:
Tu masz przyklad prostej implementacji wydajnego unsignet int set-a:
https://raw.githubusercontent.com/inveniosoftware/in
tbitset/master/intbitset/intbitset_impl.c
Pakiet jest do Pythona,
https://pypi.python.org/pypi/intbitset
ale implementacja w w/w pliku jest na tyle ogolna, ze do uzycia w C/C++
Hint-y:
intBitSetCreate/intBitSetResetFromBuffer
intBitSetAddElem
intBitSetIsInElem // sedno
intBitSetDelElem
tu tez warto "looknac": intBitSetGetTot

AK


---
Ta wiadomość została sprawdzona na obecność wirusów przez oprogramowanie antywirusowe
Avast.
https://www.avast.com/antivirus

do góry

Użytkownik "szemrany" <s...@o...off> napisał w wiadomości
news:1leex0oigz6vy$.1s1ppoj8iyjiu$.dlg@40tude.net...
> On Mon, 14 Sep 2015 14:05:12 +0200, AK wrote:
> A tu trafiłem artykuł dość chyba dobrze opisujący fundamenty tego zjawiska
> od strony psychologii i socjologii:
>
> http://tinyurl.com/n9tdaq3
>
> i pelny adres:
>
> http://serwisy.gazetaprawna.pl/edukacja/artykuly/892
103,nasze-dzieci-to-najwieksze-pierdoly-na-swiecie-h
odujemy-zombi-ktore-nie-wiedza-kim-sa.html


Równie ciekawy artykuł:
http://ciekawe.org/2015/01/24/dokad-zmierza-ludzkosc
-eksperyment-calhouna/

do góry

On Wed, 16 Sep 2015 11:40:56 +0200, AK wrote:

> Co do int set:
> Tu masz przyklad prostej implementacji wydajnego unsignet int set-a:
> https://raw.githubusercontent.com/inveniosoftware/in
tbitset/master/intbitset/intbitset_impl.c
> Pakiet jest do Pythona,
> https://pypi.python.org/pypi/intbitset
> ale implementacja w w/w pliku jest na tyle ogolna, ze do uzycia w C/C++
> Hint-y:
> intBitSetCreate/intBitSetResetFromBuffer
> intBitSetAddElem
> intBitSetIsInElem // sedno
> intBitSetDelElem
> tu tez warto "looknac": intBitSetGetTot

Dzięki, rzucę na to okiem, choć nie wiem czy podołam konwersji, bo piszę w
Delphi, a C znam "po łebkach" ;-)

ps. pytania dotyczące tego kodu, a raczej C:

register word_t *end;

co oznacza register w tej deklaracji?

base = ret->bitset = PyMem_Malloc(ret->allocated * wordbytesize);

czy PyMem_Malloc to zwykłe alokowanie pamięci, ale użyte dlatego, że to
moduł do Pythona czy ma też inne działanie niż malloc?

typedef unsigned long long int word_t;

to jest definicja typu word_t, który jest czym? 64 bity bez znaku?

Dzięki.

--
howgh
szemrany
"Trzeba z żywymi naprzód iść, po życie sięgać nowe,
a nie w uwiędłych laurów liść z uporem stroić głowę"

do góry