Użytkownik "DJ" <j...@p...onet.pl> napisał w wiadomości
news:kh9lmb$k9l$1@news.dialog.net.pl...
> On 2013-03-07 00:33:05 +0100, "Anerys" <s...@s...pl> said:
>
>> Choćby w czasach, w których to robiłem, że taka różnica była istotna. A
>> jeśli program spokojnie może byc mały, to nie widzę powodów, aby był
>> duży.
>
> Producenci widzą powód - sprzedawać większe pamięci, większe HDD, proce z
> szyną danych 64bit, w końcu musi być jakieś uzasadnienie dla "rozwoju".

Ależ ja nie zgłaszam przeciwwskazań, by rosły pojemności pamięci, dysków
twardych, ich szybkości, moce procka, szerokość szyny adresowej/danych.
Tylko serdecznie wolałbym to przeznaczyć dla danych, które miałbym obrobić,
żeby np. film w większej rozdzielczości, lepiej skompresowane audio, duże
ilości danych w ogóle, miały gdzie się pomieścić, jak zostać obrobione... A
nie dla procedur to robiących. Inaczej robi się sztuka dla sztuki. Oglądałem
kiedyś reportaż, gdzieś z... nie pamiętam, miejsce mniej-więcej jak z wojaży
Cejrowskiego pośród ludów Ameryki Południowej. Ale jego mieszkańcy zarabili
potężne pieniądze. Ale nie na luksusy życia codziennego - tak to żyli w
miarę skromnie - tylko na... swój pogrzeb, aby był z rozmachem. Tylko na to.
Tak widzę pęd ku potężnieniu nowych systemów. Ja wolę jednak zarobić, by móc
lepiej żyć. Puknąć w kalendarz mogę i w sosnową jesionkę na komunalnym parku
sztywnych, czwóreczka, czy piąteczka (rozmiar), jak mawiał Celestyn
Konfiteor, przedsiębiorca pogrzebowy z wiechowskiego Cafe pod Minogą.

--
Pod żadnym pozorem nie zezwalam na wysyłanie mi jakichkolwiek reklam,
ogłoszeń, mailingów, itd., ani nawet zapytań o możliwość ich wysyłki.
Nie przyjmuję ŻADNYCH tłumaczeń, że mój adres e-mail jest ogólnodostępny
i nie został ukryty. Wszelkie próby takich wysyłek potraktuję jako stalking.

do góry

Użytkownik "sundayman" <s...@p...onet.pl> napisał w wiadomości
news:kha4v5$dbi$1@news.task.gda.pl...
>
>> Producenci widzą powód - sprzedawać większe pamięci, większe HDD, proce
>> z szyną danych 64bit, w końcu musi być jakieś uzasadnienie dla "rozwoju".
>
> No trochę chyba przesadzacie...
> W końcu, jest chyba pewna różnica w tym, że mając atari generowałem sobie
> kreski, które miały być grafiką 3D (przy dużej dozie wyobraźni),
> a dziś na moim PC domowym mogę sobie w 10 minut wyrenderować
> fotorealistyczny obrazek czegoś, co mam pokazać klientowi.

Ależ właśnie w tym nie ma nic złego! Że dzięki szybszym i pojemniejszym
komponentom możesz łatwiej i szybciej to zrobić. Ale zdobyte pola niech
posłużą danym, a nie procedurom je macającym (przynajmniej nie więcej, niż
naprawdę potrzebują), a nie - nowszy sprzęt, to sru, bajtów nie liczymy,
program obkurczający obrazki niebawem będzie mieć 500 MB, co, bajtów nie
liczymy, bo miejsce jest... (a to, że obrazek, to 5 MB, to już mniej
ważne...)

>
> No przecież to wynika z tych "64 bitów" i paru innych rzeczy.

Nie widzę niczego złego w rozwoju. Ale niech z niego skorzysta to, co
powinno.

>
> Zgadzam się natomiast z tym, że np. pakowanie do telefonu wszystkiego poza
> telefonem, to rzeczywiście jest jakieś skrzywienie...

Ja tam z telefonu po prostu dzwonię... Mam do dziś Eryka R320s.

--
Pod żadnym pozorem nie zezwalam na wysyłanie mi jakichkolwiek reklam,
ogłoszeń, mailingów, itd., ani nawet zapytań o możliwość ich wysyłki.
Nie przyjmuję ŻADNYCH tłumaczeń, że mój adres e-mail jest ogólnodostępny
i nie został ukryty. Wszelkie próby takich wysyłek potraktuję jako stalking.

do góry

Użytkownik "sundayman" <s...@p...onet.pl> napisał w wiadomości
news:khaafm$q0m$1@news.task.gda.pl...
> Ale co by nie mówić, na nowszym komputerze render trwa krócej, a nie
> dłużej i ostatecznie to właśnie jest finalnym kryterium.

Owszem, tak jest. Ale jakby to dobrze obwąchać, to krócej... ale czy
rzeczywiście o tyle krócej, ile relatywnie wzrosła moc sprzętu?
Uważam, że jeśli moc maszyny wzrosła o 20%, to także o 20% wzrosnąć powinna
szybkość renderu. A jestem niemal pewien, że wzrosła o 10, góóra 15... Czyli
te 5 procent to strata na mocy potrzebnej nowemu programowi... Zrozumiem
jeszcze, jeśli za faktem, że program objętościowo jest większy o 50%,
pójdzie to, ze jego moc przetwarzania wzrośnie o te 10-20%, dzięki czemu,
upraszczając, na szybszej o 20% maszynie mamy render szybszy o 30-40%...

--
Pod żadnym pozorem nie zezwalam na wysyłanie mi jakichkolwiek reklam,
ogłoszeń, mailingów, itd., ani nawet zapytań o możliwość ich wysyłki.
Nie przyjmuję ŻADNYCH tłumaczeń, że mój adres e-mail jest ogólnodostępny
i nie został ukryty. Wszelkie próby takich wysyłek potraktuję jako stalking.

do góry

Użytkownik "DJ" <j...@p...onet.pl> napisał w wiadomości
news:kh9lol$k9l$2@news.dialog.net.pl...
> On 2013-03-07 00:48:24 +0100, "Anerys" <s...@s...pl> said:
>
>> Hmm... nie wiem, w czym był pisany Norton Commander, ale na XT 4.77/8
>> startował poniżej sekundy. GW-Basic (ok. 60kB) startował natychmiast. A z
>> dyskietki przez czas potrzebny do odczytania kodu programu.
>> Dzisiaj... mam maszynę 3 GHz dwurdzeniową, Total Commander startuje
>> dłużej...
>
> Ten postęp nazywa się windoza... To taki wielowątkowy stwór przygotowany
> do drapania się po wszystkim, jednocześnie. ;P

Więc i po psicie i cyckach... tylko ja ich nie mam, a program się po nich
drapie... A to zajmuje pamięć...

--
Pod żadnym pozorem nie zezwalam na wysyłanie mi jakichkolwiek reklam,
ogłoszeń, mailingów, itd., ani nawet zapytań o możliwość ich wysyłki.
Nie przyjmuję ŻADNYCH tłumaczeń, że mój adres e-mail jest ogólnodostępny
i nie został ukryty. Wszelkie próby takich wysyłek potraktuję jako stalking.

do góry

Użytkownik "Marek Borowski" <m...@...borowski.com> napisał w wiadomości
news:kh9p7j$ilo$1@news.task.gda.pl...
>> Na miarę czego? Komputera z 4 GB RAMu? Co za różnica ile zajmie hello
>> world?
> To nie tylko chodzi o hello word, to jest generalna koncepcja pisania
> programow - skladania ich z jak najbardziej uniwersalnych (a przed to
> duzych) klockow. W wielu przypadkach roznica jest glownie metalna. Ale

A taka uniwersalność to ogromne zagrożenie - wystarczy umieć się włamać do
jednego takiego uniwersalnego klocka, aby "cały świat stał przed nami
otworem".

> jak juz to ktos swietnie zauwazyl nieco dziwne jest iz program o tej miej
> wiecej tej samej fukcjonalnosci co program z przed 30 lat na 1000x
> szybszym komputerze dziala tak samo albo i wolniej. A miejsca na dysku
> zajmuje 1000x wiecej.

Lubiłem sobie przeklepywać z czasopisemka programy asemblerowe, miałem
zreszta asembler na miejscu, linker także (rok '91, komp w pracy, do obsługi
centralki przywoławczej Unipage). Program głęboko blokujący zapis na dysku
po skompilowaniu miał... zgadujcie... brawo - zgadł pan! 14 bajtów!!!
(czternaście bajtów). Dziś taki program miałby... nie próbuję nawet
zgadywać. Oczywiście, blokada była łatwo zdejmowalna ponownym wywołaniem
programu.

--
Pod żadnym pozorem nie zezwalam na wysyłanie mi jakichkolwiek reklam,
ogłoszeń, mailingów, itd., ani nawet zapytań o możliwość ich wysyłki.
Nie przyjmuję ŻADNYCH tłumaczeń, że mój adres e-mail jest ogólnodostępny
i nie został ukryty. Wszelkie próby takich wysyłek potraktuję jako stalking.

do góry

On 07.03.2013 00:33, Anerys wrote:
>
> Użytkownik "Michoo" <m...@v...pl> napisał w wiadomości
> news:kh88ul$sbc$1@mx1.internetia.pl...
>> On 06.03.2013 19:53, Anerys wrote:
>>
>>> W ogóle jest jakaś dziwna tendencja chyba we wszystkim, czy prawie
>>> wszystkim, że praktycznie identyczne, czy podobne programy, obrastają w
>>> craz większy kod wynikowy, nie usprawiedliwiony np. dodawanymi
>>> funkcjami.
>>
>> W końcu są "różne".
>
> Nie mówię, że nie...
>
>>
>>> Różne kompilatory dla dokładnie takiego samego kodu
>>> wejściowego produkują całkowicie różny w objętości kod.
>>
>> A to zależy od wielu opcji czasu kompilacji.
>
> Bezbajerowo. Jeszcze pod DOSem. TP 3 dawał ok. 30 kilku kB, TP7 już
> poniżej 10.
>
>>
>>> Weźmy z Pascala np. (darujcie "interpunkcję", ostatni raz rzeźbiłem 20
>>> lat temu...)
>>> program hello; (niektóre kompilatory OIDP pozwalają na pominięcie tej
>>> deklaracji)
>>> begin
>>> writeln ('Dzien dobry');
>>> end.
>>> jeden kompilator dał 30-kilka kB kodu,
>>
>> Bardziej rozbudowana lub nie stripowana biblioteka.
>
> Tylko po co ona, gdy jedynym zadaniem programu było krok po kroku
> wyrzucić kilkanaście znaków na ekran... w C64 schodziłęm poniżej 50
> bajtów włącznie z danymi (fakt, skakałem do podprogramu... ale gdzieś
> widziałem listing, który bezpśrednio dawał... i nie obrosło to w zbędny
> kod. Ale to w C64 był mus, liczył się każdy bajt. I dobrze.
>
>>
>>> inny ok. 7,
>>
>> Mniej rozbudowana (albo np wolniejsza) biblioteka. 30 kB to żaden
>> rozmiar, więc w czym problem?
>
> Choćby w czasach, w których to robiłem, że taka różnica była istotna. A
> jeśli program spokojnie może byc mały, to nie widzę powodów, aby był duży.
>
>>
>>> A robiły dokładnie to samo. Zero dołączeń,
>>
>> a writeln to skąd się niby wzięło?
>
> Z treści programu. Nic nie było definiowane w treści przez include,
> żadnej dyrektywy dołączającej, nic, poza tymi 4 liniami.
>
>>
>>> zero innych
>>> deklaracji, itp. a doklejały kilkadziesiąt kB ch.j wie czego, psu na
>>> budę potrzebnego...
>>
>> A potem jak się trochę więcej napisało to nagle ten pierwszy tył o
>> dodatkowe kilka kB kodu a ten drugi o kilkadziesiąt.
>
> Klepałem trochę, ale już zapomniałem szczegółów... tylko czemu
> wspomniany przeze mnie Zdzich umiał się zachować i nie tył zanadto?

Znasz różnicę pomiędzy PE a COM? Wiesz co to symbole debugowe? Przykłąd
z pod linuxa:
$ ls -lh ATmegaBOOT_644P.elf
-rwxr-xr-x 1 michoo michoo 14K mar 6 23:47 ATmegaBOOT_644P.elf
$ avr-size ATmegaBOOT_644P.elf
text data bss dec hex filename
1880 0 265 2145 861 ATmegaBOOT_644P.elf
$ avr-strip ATmegaBOOT_644P.elf
$ ls -lh ATmegaBOOT_644P.elf
-rwxr-xr-x 1 michoo michoo 2,2K mar 7 11:48 ATmegaBOOT_644P.elf

>
>>> Jestem niemal pewien, że gdyby tu i ówdzie poobcinać fuzle, to programy
>>> zrobiły by się mniejsze... tylko może kompilatory powinny rzetelniej
>>> generować kod? Nie doklejać czegoś, co programowi nie jest potrzebne.
>>
>> Po grzyba ktoś ma optymalizować kompilator pod kątem minimalnego
>> programu, który nic nie robi?
>
> Robi - wyświetla na ekranie "Dzien dobry" (bez ogonka, bo wtedy ich
> prawie nie znano(1991))
> Ja chcę od programu, aby mając tekst j.w., program zrobił:
> Licząc od pierwszego do ostatniego znaku, pobrał je po kolei i wyrzucił
> na ekran. Niech 100 bajtów kodu pobiera te znaki, drugie 100 wyprowadzi
> na ekran, trzecie 100 utrzyma to w całości. Już nie będę aż tak skąpy.

To czemu kazałeś mu wywołać funkcję biblioteki writeln, która +- robi
właśnie to, ale pochodzi z biblioteki, ktora dodatkowo zawiera takie
"bezsensowne" rzeczy jak:
inicjalizacja stosu, przygotowanie obsługi wyjątków, inicjalizację
alokatora, sam alokator, alokacja konsoli...?

> Ale, żeby to nie było po 10 kB, bo co by te 10 kB robiło w swojej części
> zadania... czy ile tego było... skoro setka poradziłą sobie równie
> dobrze... to co robi pozostałe 9900 bajtów? Ja je chcę wyrzucić. Tylko
> tyle.

Głupia IKONA dla programu to np 10k. Po kiego grzyba pisać środowisko,
które usunie z biblioteki "niepotrzebne" funkcje w tak nieistotnym
przypadku jak "program, który nic nie robi" i rozmiarze 20k? Domagasz
się, żeby ktoś dokonał masy zbędnej optymalizacji w imię czego?

A jak chcesz rzeźbić to droga wolna - pisałem programy windowsowe,
okienkowe z rozmiarem po skompilowaniu 512-1024B. MASM jest do tego
bardzo wygodny.

--
Pozdrawiam
Michoo

do góry

W dniu 2013-03-04 15:25 JDX napisał(a):

> BTW. Również uważam, że MCS-51 to koszmar programisty. :-D

Zgadzam się z powyższym w całej rozciągłości.

Niech ten wynalazek (C) Intel 1980 odejdzie w końcu w niebyt.

--
Adam Dybkowski
http://dybkowski.net/

Uwaga: przed wysłaniem do mnie maila usuń cyfry z adresu.

do góry

W dniu 2013-03-07 22:22, Adam Dybkowski pisze:
> W dniu 2013-03-04 15:25 JDX napisał(a):
>
>> BTW. Również uważam, że MCS-51 to koszmar programisty. :-D
>
> Zgadzam się z powyższym w całej rozciągłości.
>
> Niech ten wynalazek (C) Intel 1980 odejdzie w końcu w niebyt.

a co powiesz na to:
http://microcontroller.com/news/Zilog_Z8051.asp
?

--
Pozdr.
Michał

do góry

On 2013-03-07 17:19, Grzegorz Niemirowski wrote:
> Marek Borowski <m...@...borowski.com> napisał(a):
>> No wiec jakbys byl kiedys czlonkiem demosceny to bys zrozumial, ze
>> moga byc inne powody.
>
> Rozumiałem je jeszcze zanim zobaczyłem pierwsze demo. Ale to, że je
> rozumiem, nie oznacza, że uważam za słuszne stosowanie ich zawsze i
> wszędzie. Z resztą sam fakt, że przywołałeś scenę świadczy o tym, że te
> powody są czymś niszowym (niezależnie od tego czy to dobrze czy źle).
>
Uwzgledniajac realia jak najbardziej sie zgadzam.

>> Ale co to ma za znaczenie ? Jak juz pisalem w tym watku pojecie "ma
>> sens" nie jest zwiazane z ekonomia czy czasem pisania programu czy
>> wysilkiem w to wlozonym. Oceniamy absolutnie. Czyli szybszy i mniejszy
>> z o tej samej ilosci bledow jest lepszy, niezaleznie czy jego
>> wywtorzenie zajelo 10lat i kosztowalo 10 mld $ czy nie.
>
> Jest lepszy, tylko często po prostu nie ma to znaczenia.
>
Oczywiscie. Czepiam sie uzywania kryteriow pozatechnicznych do oceny czy
cos jest dobre czy zle - jestem technokrata. Jesli by to odemnie
zalezalo "wystrzelalbym" wszystkich marketingowcow i ksiegowych.

Pozdrawiam

Marek

do góry

> A jak chcesz rzeźbić to droga wolna - pisałem programy windowsowe,
> okienkowe z rozmiarem po skompilowaniu 512-1024B. MASM jest do tego
> bardzo wygodny.

a ja pierszy program pisałem na kartce w assemblerze Z80, na "komputer"
ZX81, który miał 1KB ramu, w czym połowa chyba na pamięć ekranu :)

Tam się liczył każdy bajt - kto dziś pamięta takie rzeczy :)
A dodatkowo ten komputer miał od tyłu postawioną suszarkę do włosów,
która nie grzała, ale dmuchała zimnym powietrzem, bo miałem uwalony ULA,
i bez tego po paru minutach się przegrzewał, i zawieszał wszystko w diabły.

I - co, można było ?? Można !

do góry