Hoi,

Ik vraag mezelf af waarom software steeds langzamer wordt terwijl hardware
steeds sneller wordt.

Natuurlijk: er komt meer functionaliteit bij. Vroeger hadden we bitmap
fonts, nu vector fonts en dat is nu eenmaal wat trager, enz. enz.

Maar dan nog: is dat functionaliteit verhaal eigenlijk gewoon geen onzin
verhaal? Is het niet gewoon dat tegenwoordig softwareontwikkelaars en de
bedrijven waar ze werken gewoon lui zijn, het niet weten en/of snel geld
willen verdienen?

Kortom: is veel software inefficient geschreven of valt het wel mee? Volgens
mij is snelheid geen topic meer, want dan moet je maar een nieuwe computer
kopen zo is ongetwijfeld de gedachte?

Hoe denk jij hierover? Als jij het er niet mee eens bent, waarom niet? En
als je het er (gedeeltelijk) wel mee eens bent, wat is volgens jou de
oorzaak, etc.?

Groetjes,

Hans

On 2004-04-25, Hans <nospam> wrote:
> Ik vraag mezelf af waarom software steeds langzamer wordt terwijl hardware
> steeds sneller wordt.
>
> Natuurlijk: er komt meer functionaliteit bij. Vroeger hadden we bitmap
> fonts, nu vector fonts en dat is nu eenmaal wat trager, enz. enz.
>
> Maar dan nog: is dat functionaliteit verhaal eigenlijk gewoon geen onzin
> verhaal? Is het niet gewoon dat tegenwoordig softwareontwikkelaars en de
> bedrijven waar ze werken gewoon lui zijn, het niet weten en/of snel geld
> willen verdienen?

Dat zeker, maar de ontwikkelaars zijn niet de enige schuld.

Toeters en bellen worden gevraagd door de klanten, en de klanten forceren
deels ook de snelle cycli van windows en office versies. (denk aan de
release van XP, aan het aantal mensen dat al beta's draaide, en die naar XP
RTM gingen nog voor de release, en binnen korte tijd erna)

> Kortom: is veel software inefficient geschreven of valt het wel mee? Volgens
> mij is snelheid geen topic meer, want dan moet je maar een nieuwe computer
> kopen zo is ongetwijfeld de gedachte?

Waarom heb jij nieuwe software nodig? Het hele principe berust op het feit
dat jij een nieuw OS en nieuwe apps wil hebben, die je vervolgens meerdere
keren met andere opmaak verkocht worden.

Maar deels kan je het inderdaad niet onwijken. Zo is b.v. de software bij
Canon camera's nodeloos traag op een ouder systeempje (+/- 300 MHz)

Hans wrote:

> Hoi,
>
> Ik vraag mezelf af waarom software steeds langzamer wordt terwijl hardware
> steeds sneller wordt.
>
> Natuurlijk: er komt meer functionaliteit bij. Vroeger hadden we bitmap
> fonts, nu vector fonts en dat is nu eenmaal wat trager, enz. enz.

Vroeger had ik al vectorfonts, eh, 1988 of zo :-D (RISC OS)

> Maar dan nog: is dat functionaliteit verhaal eigenlijk gewoon geen onzin
> verhaal? Is het niet gewoon dat tegenwoordig softwareontwikkelaars en de
> bedrijven waar ze werken gewoon lui zijn, het niet weten en/of snel geld
> willen verdienen?
>
> Kortom: is veel software inefficient geschreven of valt het wel mee? Volgens
> mij is snelheid geen topic meer, want dan moet je maar een nieuwe computer
> kopen zo is ongetwijfeld de gedachte?
>
> Hoe denk jij hierover? Als jij het er niet mee eens bent, waarom niet? En
> als je het er (gedeeltelijk) wel mee eens bent, wat is volgens jou de
> oorzaak, etc.?

Oorzaak: allerlei fratsen die je nauwelijks nodig hebt, maar die mensen
als maatstaf gebruiken van hoe goed iets is: skinnen en geluidjes.

Daarnaast worden er "dikke" componenten gebruikt, zo wordt een halve
browser gebruikt in een emailprogramma om HTML te kunnen renderen.

Ik verbaas mij er ook over als ik zie dat Thunderbird (Mail/Usenet) 28
MB vreet, Messenger in rust 3 MB (bij gebruik zit het volgens mij zo op
11 MB).

En dan herinner ik mij de tijd waar een leuk DTP pakket 900 K was, en
dat echt een omvangrijke executable was in die dagen, op dat systeem
(Acorn Archimedes).

Oorzaak? Ik denk dat er te veel dikke componenten gebruikt worden. Alsof
je een editor maakt, met een browsercomponent, omdat je dan netjes
verschillende fonts kan renderen.

Hans (nospam) wrote:
> Ik vraag mezelf af waarom software steeds langzamer wordt terwijl hardware
> steeds sneller wordt.
>
> Natuurlijk: er komt meer functionaliteit bij. Vroeger hadden we bitmap
> fonts, nu vector fonts en dat is nu eenmaal wat trager, enz. enz.
>
> Maar dan nog: is dat functionaliteit verhaal eigenlijk gewoon geen onzin
> verhaal? Is het niet gewoon dat tegenwoordig softwareontwikkelaars en de
> bedrijven waar ze werken gewoon lui zijn, het niet weten en/of snel geld
> willen verdienen?
>
> Kortom: is veel software inefficient geschreven of valt het wel mee? Volgens
> mij is snelheid geen topic meer, want dan moet je maar een nieuwe computer
> kopen zo is ongetwijfeld de gedachte?
>
> Hoe denk jij hierover? Als jij het er niet mee eens bent, waarom niet? En
> als je het er (gedeeltelijk) wel mee eens bent, wat is volgens jou de
> oorzaak, etc.?

Vroeger was het inderdaad nodig om klein, snel en efficient te
programmeren. Deed je dat niet, dan draaide je applicatie traag
of zelfs helemaal niet.
Echter, om op die manier te programmeren heeft een aantal grote
nadelen:

- het kost veel tijd en dus geld
- je programma gaat waarschijnlijk heel specifiek op hardware
geschreven worden. Portabiliteit is lastig dus.
- interoperatie met andere applicaties, zeker als ze van een
andere fabrikant zijn, zal moeilijk zijn.
- gebruikersvriendelijkheid zal snel ondergeschikt worden aan de
snelheid.

Zoals je al zegt: de fonts. Leuk voorbeeldje. Kijk nu eens naar
een applicatie uit 1992. Het ziet er werkelijk vreselijk uit.

Waarom toen niet? Ten eerste omdat de beeldschermen toen nog lang
niet zo goed waren als nu. Anti-aliassing was domweg nog niet
nodig, maar wegens de onscherpte van die monitor zag alles er
toch wel al wat afgerond uit ;-)

Nu loer je naar 1280x1024 of hoger, met een grote kleurdiepte,
fantastische scherpte, enz. En dan liggen je standaarden opeens
een stuk hoger. De ergonomie is gewoon enorm toegenomen. En ja,
dat gaat ten koste van wat snelheid, maar dat wordt meer dan
gecompenseerd met brute rekenkracht.

De grotere rekenkracht stelt een programmeur ook in staat om te
schrijven in een hogere programmeertaal, zodat hij zich meer op
het probleem kan concentreren dan op het uithalen van allemaal
truukjes om alles maar snel te laten draaien.

En dat is denk ik waar het allemaal om draait: programmeren wordt
minder low-level, het wordt minder werken met computers en meer
met de dingen waar het *echt* om gaat.

Marco van de Voort wrote:

> On 2004-04-25, Hans <nospam> wrote:
>> Dat zeker, maar de ontwikkelaars zijn niet de enige schuld.
>
> Toeters en bellen worden gevraagd door de klanten, en de klanten forceren
> deels ook de snelle cycli van windows en office versies.

Werkelijk? Ik dacht altijd dat nieuwe versies gemaakt werden om geld
binnen te halen. Daarom is software nooit af. Ik ken 1 praktijkgeval,
misschien een beetje daardoor overstuurd, maar daar moesten de klanten
bijna gedwongen worden om over te schakelen :-D.

Erik Hensema wrote:

> Vroeger was het inderdaad nodig om klein, snel en efficient te
> programmeren. Deed je dat niet, dan draaide je applicatie traag
> of zelfs helemaal niet.
> Echter, om op die manier te programmeren heeft een aantal grote
> nadelen:
>
> - het kost veel tijd en dus geld

Klopt, zeker als dingen in assembly geschreven moesten worden.

> - je programma gaat waarschijnlijk heel specifiek op hardware
> geschreven worden. Portabiliteit is lastig dus.

Dat is soms totaal niet van toepassing, voor Windows zeker niet.

> - interoperatie met andere applicaties, zeker als ze van een
> andere fabrikant zijn, zal moeilijk zijn.

Waarom? Iets wat compact in assembly geschreven is kan nog steeds prima
bestanden uitwisselen.

> - gebruikersvriendelijkheid zal snel ondergeschikt worden aan de
> snelheid.

Ook dat hoeft niet. Ik vind al die bloated skin rommel niet bijdragen
aan gebruikersvriendlijkheid. Windows Media Player is een mooi voorbeeld.

> Zoals je al zegt: de fonts. Leuk voorbeeldje. Kijk nu eens naar
> een applicatie uit 1992. Het ziet er werkelijk vreselijk uit.

Welk platform?

> Waarom toen niet? Ten eerste omdat de beeldschermen toen nog lang
> niet zo goed waren als nu. Anti-aliassing was domweg nog niet
> nodig, maar wegens de onscherpte van die monitor zag alles er
> toch wel al wat afgerond uit ;-)

Nooit met Eizo gewerkt? Ooit wel eens een Archimedes met Eizo Monitor
gezien naast een windows doos in 1988?

> De grotere rekenkracht stelt een programmeur ook in staat om te
> schrijven in een hogere programmeertaal, zodat hij zich meer op

Een hogere programmeertaal wil niet zeggen: resultaat werkt trager.

> het probleem kan concentreren dan op het uithalen van allemaal
> truukjes om alles maar snel te laten draaien.

Dat moet nog steeds, zie onder.

> En dat is denk ik waar het allemaal om draait: programmeren wordt
> minder low-level, het wordt minder werken met computers en meer
> met de dingen waar het *echt* om gaat.

Proest. Hoelang programmeer je al? Ik zie niet echt veel verschil met 20
jaar terug, qua programmeren. Ok, als je een GUI applicatie in elkaar
wilt zetten, dat kan iets handiger met drag & drop. Maar het echte
programmeren moet nog steeds gebeuren, en nog steeds lowlevel. Nog
steeds een bestand openen, kijken of het lukt, schrijven, lukt dat,
sluiten, lukt dat enz.

Andere vergissing die je maakt, veel dingen moeten nog steeds efficient.
Twintig jaar terug was een bestand van 1 MB groot, nu is een bestand van
een paar gigabyte normaal. En als je niet efficient programmeerd, dan
loop je tegen problemen op als je met dergelijke bestanden omgaat.

Toen ik Erik Hensema kietelde, kwam er dit uit:

> Nu loer je naar 1280x1024 of hoger, met een grote kleurdiepte,
> fantastische scherpte, enz. En dan liggen je standaarden opeens
> een stuk hoger. De ergonomie is gewoon enorm toegenomen. En ja,
> dat gaat ten koste van wat snelheid, maar dat wordt meer dan
> gecompenseerd met brute rekenkracht.

Die 1280x1024 (of toch liever 1600x1200 en daar dan de 16:9
variant van) kan prima in OpenGL (of Display-Postscript) worden
aangestuurd. Als de videokaart daar dan in gespecialiseerd is
dan hoeft de processor niet zo'n supersnelle te zijn.

On 2004-04-25, John Bokma <postmaster> wrote:

>>>Maar dan nog: is dat functionaliteit verhaal eigenlijk gewoon geen onzin
>>>verhaal? Is het niet gewoon dat tegenwoordig softwareontwikkelaars en de
>>>bedrijven waar ze werken gewoon lui zijn, het niet weten en/of snel geld
>>>willen verdienen?
>>
>> Dat zeker, maar de ontwikkelaars zijn niet de enige schuld.
>>
>> Toeters en bellen worden gevraagd door de klanten, en de klanten forceren
>> deels ook de snelle cycli van windows en office versies.
>
> Werkelijk? Ik dacht altijd dat nieuwe versies gemaakt werden om geld
> binnen te halen.

Maar om geld binnen te halen moeten die gekocht worden.

> Daarom is software nooit af. Ik ken 1 praktijkgeval, misschien een beetje
> daardoor overstuurd, maar daar moesten de klanten bijna gedwongen worden
> om over te schakelen :-D.

Teveel mensen upgraden software alleen om het upgraden, vooral omdat het
gros illegale software gebruikt, en de upgrade niks kost.

On 2004-04-25, Erik Hensema <usenet> wrote:

>>
>> Hoe denk jij hierover? Als jij het er niet mee eens bent, waarom niet? En
>> als je het er (gedeeltelijk) wel mee eens bent, wat is volgens jou de
>> oorzaak, etc.?
>
> Vroeger was het inderdaad nodig om klein, snel en efficient te
> programmeren. Deed je dat niet, dan draaide je applicatie traag
> of zelfs helemaal niet.
> Echter, om op die manier te programmeren heeft een aantal grote
> nadelen:
>
> - het kost veel tijd en dus geld
> - je programma gaat waarschijnlijk heel specifiek op hardware
> geschreven worden. Portabiliteit is lastig dus.

- 99% van de software is windows only, en een groot deel in de praktijk
zelfs nog maar een gelimiteerd aantal versies.
- Portabiliteit vereist geen fat binaries. Tuurlijk, je kan net zo goed
lagen software stapelen vanwege portabiliteit als vanwege
elke andere reden, maar het hoeft niet.

> - interoperatie met andere applicaties, zeker als ze van een
> andere fabrikant zijn, zal moeilijk zijn.

Die logica zie ik ook niet.

> - gebruikersvriendelijkheid zal snel ondergeschikt worden aan de
> snelheid.

Lamme applicaties zijn niet gebruikersvriendelijk.

> Zoals je al zegt: de fonts. Leuk voorbeeldje. Kijk nu eens naar
> een applicatie uit 1992. Het ziet er werkelijk vreselijk uit.

Vind ik best meevallen. Ik vind eerlijk gezegd geskinnde bonte apps
oerlelijk. Maar goed, het stadium van fluor gele stereotorens met
meer lichtjes dan Philips in Eindhoven heeft heb ik ook overgeslagen.

> Waarom toen niet? Ten eerste omdat de beeldschermen toen nog lang
> niet zo goed waren als nu. Anti-aliassing was domweg nog niet
> nodig, maar wegens de onscherpte van die monitor zag alles er
> toch wel al wat afgerond uit ;-)

Van anti aliasing in een system lib wordt je binary niet groter.

> Nu loer je naar 1280x1024 of hoger, met een grote kleurdiepte,
> fantastische scherpte, enz. En dan liggen je standaarden opeens
> een stuk hoger. De ergonomie is gewoon enorm toegenomen. En ja,
> dat gaat ten koste van wat snelheid, maar dat wordt meer dan
> gecompenseerd met brute rekenkracht.

Dit wordt allemaal grotendeels door de (geaccellereerde) driver afgehandeld,
heeft op wat grafische software na geen impact op de app denk ik.

> De grotere rekenkracht stelt een programmeur ook in staat om te
> schrijven in een hogere programmeertaal, zodat hij zich meer op
> het probleem kan concentreren dan op het uithalen van allemaal
> truukjes om alles maar snel te laten draaien.

Of om een stuk goedkopere programmeur binnen te halen natuurlijk. En
die let niet op of de laag te dik wordt.

> En dat is denk ik waar het allemaal om draait: programmeren wordt
> minder low-level, het wordt minder werken met computers en meer
> met de dingen waar het *echt* om gaat.

TMF, maar dan geskinned op je applicatie. Tsja, mooi of productief is het
niet, maar de klant vraagt er inderdaad om.

Marco van de Voort wrote:

> On 2004-04-25, John Bokma <postmaster> wrote:
>>
> Maar om geld binnen te halen moeten die gekocht worden.

Precies, en dat wordt meestal gewoon niet gedaan.

>>Daarom is software nooit af. Ik ken 1 praktijkgeval, misschien een beetje
>>daardoor overstuurd, maar daar moesten de klanten bijna gedwongen worden
>>om over te schakelen :-D.
>
> Teveel mensen upgraden software alleen om het upgraden, vooral omdat het
> gros illegale software gebruikt, en de upgrade niks kost.

Ok, de mensen die illegaal software gebruiken tellen we niet mee, want
die kopen het toch niet, en ik denk dat geen enkele fabrikant upgrades
maakt om de illegale gebruikers blij te maken.

Blijven de betalende gebruikers over. Denk je werkelijk dat die allemaal
Office 2005 willen? Ikzelf heb nog steeds Office 97. Ik zou niet weten
wat ik met al die nieuwe versies meer kan doen. En ik denk dat dat voor
veel mensen geld. Idem met Windows versies. Hoeveel betalende gebruikers
gebruiken nog vrolijk '98? ME? 2000?.

In bedrijfssituaties gaat het upgraden veel en veel trager. Denk maar
niet dat daar even elk jaar een upgrade wordt neergezet, omdat er meer
toeters en bellen zijn.

Nee, ik denk dat de fabrikant elk jaar toeters en bellen verzint, en
zorgt dat de oude versies problemen hebben met die nieuwe toeters en
bellen (nieuw bestandsformaat e.d.), zodat als er een paar bedrijven
upgraden, de rest moet volgen om uitwisselbaar te blijven. En ik denk
dat XML dat niet gaat veranderen :-D.

John Bokma (postmaster) wrote:
> Erik Hensema wrote:
>> Klopt, zeker als dingen in assembly geschreven moesten worden.
>> Dat is soms totaal niet van toepassing, voor Windows zeker niet.
>> Waarom? Iets wat compact in assembly geschreven is kan nog steeds prima
> bestanden uitwisselen.

Uiteraard, alles kan in assembly. Maar echt leuk is het niet.

Overigens heb ik het niet alleen over het uitwisselen van
bestanden, maar ook over component-technologie, 'network-
awareness' en dat soort dingen.

>> - gebruikersvriendelijkheid zal snel ondergeschikt worden aan de
>> snelheid.
>
> Ook dat hoeft niet. Ik vind al die bloated skin rommel niet bijdragen
> aan gebruikersvriendlijkheid. Windows Media Player is een mooi voorbeeld.

Uiteraard, niet alles is altijd maar goed.

>> Zoals je al zegt: de fonts. Leuk voorbeeldje. Kijk nu eens naar
>> een applicatie uit 1992. Het ziet er werkelijk vreselijk uit.
>
> Welk platform?

Vrijwel alles. Misschien dat er wel voorbeelden zijn van goed
uitziende applicaties, maar dat was toen meer uitzondering dan
regel.

>> Waarom toen niet? Ten eerste omdat de beeldschermen toen nog lang
>> niet zo goed waren als nu. Anti-aliassing was domweg nog niet
>> nodig, maar wegens de onscherpte van die monitor zag alles er
>> toch wel al wat afgerond uit ;-)
>
> Nooit met Eizo gewerkt? Ooit wel eens een Archimedes met Eizo Monitor
> gezien naast een windows doos in 1988?

Eizo werk ik regelmatig mee. Ik weet ook wat het spul kost.

>> De grotere rekenkracht stelt een programmeur ook in staat om te
>> schrijven in een hogere programmeertaal, zodat hij zich meer op
>
> Een hogere programmeertaal wil niet zeggen: resultaat werkt trager.

Nee, maar vaak wel. Maar andersom kan ook natuurlijk: in assembly
programmeer je liever klein dan dat je meer code gebruikt voor
een slimmer algorithme. Best mogelijk dat je in een hoge taal
slimmer gaat programmeren en dat het resultaat dus sneller is.

>
> Dat moet nog steeds, zie onder.
>> Proest. Hoelang programmeer je al? Ik zie niet echt veel verschil met 20
> jaar terug, qua programmeren. Ok, als je een GUI applicatie in elkaar
> wilt zetten, dat kan iets handiger met drag & drop. Maar het echte
> programmeren moet nog steeds gebeuren, en nog steeds lowlevel. Nog
> steeds een bestand openen, kijken of het lukt, schrijven, lukt dat,
> sluiten, lukt dat enz.

Klopt, maar tegenwoordig stuur je geen printers meer direct aan,
schrijf je niet naar het videogeheugen, zit tcp/ip keurig in het
OS, enz, enz.

> Andere vergissing die je maakt, veel dingen moeten nog steeds efficient.
> Twintig jaar terug was een bestand van 1 MB groot, nu is een bestand van
> een paar gigabyte normaal. En als je niet efficient programmeerd, dan
> loop je tegen problemen op als je met dergelijke bestanden omgaat.

Klopt, ik zeg ook niet dat je nu dom mag programmeren, of dat
alles zomaar werkt als je er maar genoeg CPU of RAM tegenaan
smijt. Ik zeg alleen dat je nu makkelijker kunt kiezen voor
features die rekenkracht vereisen.

Marco van de Voort (marcov) wrote:
> On 2004-04-25, Erik Hensema <usenet> wrote:
>> - 99% van de software is windows only, en een groot deel in de praktijk
> zelfs nog maar een gelimiteerd aantal versies.

Windows is een OS dat een abstractielaag om de hardware vormt.
Net als elk OS tegenwoordig trouwens.
Door die abstractielaag gaat code al snel beter portible worden
(wat overigens niet zegt dat je zomaar alles overal kunt draaien
natuurlijk).

Vroeger had je dingen als DOS. Toen kon je nog echt op de
hardware schrijven. Sterker nog: dat was toen regel, geen
uitzondering.

> - Portabiliteit vereist geen fat binaries. Tuurlijk, je kan net zo goed
> lagen software stapelen vanwege portabiliteit als vanwege
> elke andere reden, maar het hoeft niet.
>
>> - interoperatie met andere applicaties, zeker als ze van een
>> andere fabrikant zijn, zal moeilijk zijn.
>
> Die logica zie ik ook niet.

Het kost moeite om te maken, het kost schijfruimte en het kost
ramgeheugen.
Nu pak je er gewoon een of andere library bij en maak je je geen
zorgen om die halve MB meer ruimte op schijf of in het geheugen.

>> - gebruikersvriendelijkheid zal snel ondergeschikt worden aan de
>> snelheid.
>
> Lamme applicaties zijn niet gebruikersvriendelijk.

Dat is van alle tijden.

>> Zoals je al zegt: de fonts. Leuk voorbeeldje. Kijk nu eens naar
>> een applicatie uit 1992. Het ziet er werkelijk vreselijk uit.
>
> Vind ik best meevallen. Ik vind eerlijk gezegd geskinnde bonte apps
> oerlelijk. Maar goed, het stadium van fluor gele stereotorens met
> meer lichtjes dan Philips in Eindhoven heeft heb ik ook overgeslagen.

Je kunt best een mooi ingetogen design gebruiken dat gigantisch
veel mooier is dan de gemiddelde windows 1.0 applicatie.

>> Waarom toen niet? Ten eerste omdat de beeldschermen toen nog lang
>> niet zo goed waren als nu. Anti-aliassing was domweg nog niet
>> nodig, maar wegens de onscherpte van die monitor zag alles er
>> toch wel al wat afgerond uit ;-)
>
> Van anti aliasing in een system lib wordt je binary niet groter.

Klopt. Maar dat is *zo* vreselijk oninteressant. Grootte van je
binary heeft vrijwel geen relatie met het uiteindelijke
geheugengebruik, uitvoersnelheid, enz.

>> Nu loer je naar 1280x1024 of hoger, met een grote kleurdiepte,
>> fantastische scherpte, enz. En dan liggen je standaarden opeens
>> een stuk hoger. De ergonomie is gewoon enorm toegenomen. En ja,
>> dat gaat ten koste van wat snelheid, maar dat wordt meer dan
>> gecompenseerd met brute rekenkracht.
>
> Dit wordt allemaal grotendeels door de (geaccellereerde) driver afgehandeld,
> heeft op wat grafische software na geen impact op de app denk ik.

Precies. En dat kon een aantal jaren geleden domweg nog niet.

>> De grotere rekenkracht stelt een programmeur ook in staat om te
>> schrijven in een hogere programmeertaal, zodat hij zich meer op
>> het probleem kan concentreren dan op het uithalen van allemaal
>> truukjes om alles maar snel te laten draaien.
>
> Of om een stuk goedkopere programmeur binnen te halen natuurlijk. En
> die let niet op of de laag te dik wordt.
>
>> En dat is denk ik waar het allemaal om draait: programmeren wordt
>> minder low-level, het wordt minder werken met computers en meer
>> met de dingen waar het *echt* om gaat.
>
> TMF, maar dan geskinned op je applicatie. Tsja, mooi of productief is het
> niet, maar de klant vraagt er inderdaad om.

De klant heeft interactie met je applicatie. Het gaat niet om de
functionaliteit van een applicatie, het gaat veel meer om hoe je
die functionaliteit aanspreekt. Er moet ook nog mee gewerkt
worden immers.

Als de klant dat graag wil doen in een interface die schattige
animaties vertoont, knipperende lichtjes heeft en volledig
skinbaar is: so be it. Niet zo leuk voor de techneut die het moet
schrijven, tot het moment dat die techneut betaald gaat worden
;-)

"Hans" <nospam> wrote in message
news:2eh1
> Hoi,
>
> Ik vraag mezelf af waarom software steeds langzamer wordt terwijl hardware
> steeds sneller wordt.

Feitelijk is dit onjuist.
Levendig bewijs is de game industrie. Vroeger was bij de eerste 3D games,
minimaal 25 frames per seconde nodig. Nu nog steeds, maar er worden wel 32
bits kleuren, details en meer diepte bijgehouden.

> Natuurlijk: er komt meer functionaliteit bij. Vroeger hadden we bitmap
> fonts, nu vector fonts en dat is nu eenmaal wat trager, enz. enz.
>
> Maar dan nog: is dat functionaliteit verhaal eigenlijk gewoon geen onzin
> verhaal? Is het niet gewoon dat tegenwoordig softwareontwikkelaars en de
> bedrijven waar ze werken gewoon lui zijn, het niet weten en/of snel geld
> willen verdienen?

Nog een voorbeeld. Microsoft Access 2.0 (16 bits Windows 3.x versie) was nog
geschreven in Assembly. Razendsnel! Maar versie 95, de eerste 32 bits Access
applicatie, nam minimaal 2x zoveel geheugen in beslag en was 2x zo traag in
veel gevallen.
Waarom? Ze hadden het herschreven met C++ en 32 bits instructies, zijn
natuurlijk 2x zo groot.
Maar als MS access 2.0 functionaliteit zo had gehouden, dan was inmiddels
Access 2000/2003 echt wel 2x zo snel wegens optimalisaties. Alleen, deze
optimalisaties vallen weg, zodra je met HTML / XML aan de slag gaat.

> Kortom: is veel software inefficient geschreven of valt het wel mee?
Volgens
> mij is snelheid geen topic meer, want dan moet je maar een nieuwe computer
> kopen zo is ongetwijfeld de gedachte?
>
> Hoe denk jij hierover? Als jij het er niet mee eens bent, waarom niet? En
> als je het er (gedeeltelijk) wel mee eens bent, wat is volgens jou de
> oorzaak, etc.?

1) Kijk eens naar de historie van ontwikkelen.
De eerste programmeurs programmeerden HEX ops.
De volgenden gebruikten een mnemonic (zoals assembly).
Daarna kwam C, BASIC jadda jadda, tot nu Java en .NET

Wat opvallend is, dat hoe verder de tijd, hoe minder efficient (overhead) de
instructies zijn die de taal produceert. Maar dit wordt **gecompenseerd**
door betere hardware. De programmeur daarintegen, kan in steeds *minder*
tijd *meer* functionaliteit schrijven.

(ps: Ik heb nog een oud BASIC PDS 7.x programmaatje, een label printer
software, dit was in de tijd van DOS een paar opstart seconden, en ik
optimaliseerde dat door te linken met stubs ;=), nu is hetzelfde
programaatje nog steeds ergens in mijn archieven. Toen ik het opstartte, was
het oneindigsnel opgestart :)

2) Een andere interessante ontwikkeling ligt op data opslag.

Vroeger werden data bestandjes binair opgeslagen, en was 'random' access met
een index op een sleutel erop, -hot-. Daarna kregen we op de PC dbase
toepassingen die eenvoudig relationele theorie een beetje toepasbaar maakte.
Omdat uitwisselen van gegevens steeds belangrijker wordt, en de hoeveelheid
RAM en de snelheid van harddisks sneller wordt, is het 'efficient' opslaan
van binaire data niet zo belangrijkmeer.


Oracle/Sybase en SQL server, begonnen allen als binair opslag, SQL 2003/2004
(precies nummer weet ik niet) zal zelfs 'native' XML opslag gaan toepassen.
Feitelijk is XML opslag best inefficient en vereist veel meer rekenwerk dan
relationele databases, maar what the heck? Uiteindelijk krijgen bedrijven
eenvoudiger dataopslag en retrievel voor minder geld.

Ook bij dataopslag zie je een mindere efficientie van opslag en
datamanipulatie, maar dit wordt gecompenseerd door de hardware, precies
zoals je opmerkte.

Hans wrote:

> Ik vraag mezelf af waarom software steeds langzamer wordt terwijl hardware
> steeds sneller wordt.
>
> Hoe denk jij hierover? Als jij het er niet mee eens bent, waarom niet? En
> als je het er (gedeeltelijk) wel mee eens bent, wat is volgens jou de
> oorzaak, etc.?

Software ontwikkelen kost tijd. Deze software optimaliseren op snelheid
en geheugegebruik kost daar een veelvoud van.

Stel, bedrijf A maakt snel een applicatie die het snel in de markt zet
voor een redelijk bedrag en misschien met nog wat foutjes.

Bedrijf B wil een kwalitatief goede applicatie maken en is daar langer
mee bezig. Het komt ook later op de markt en is een stuk duurder.

Bedrijf A is ondertussen marktleider en kan de inmiddels opgestreken
winst gebruiken om de bugs eruit te halen en versie 2 te verkopen.
Bedrijf B blijft een niche-speler.

Welk bedrijf wil je zijn?

Groeten,
Edwin Martin

Erik Hensema wrote:

> John Bokma (postmaster) wrote:
>
>>Erik Hensema wrote:
>>
>>Waarom? Iets wat compact in assembly geschreven is kan nog steeds prima
>>bestanden uitwisselen.
>
> Uiteraard, alles kan in assembly. Maar echt leuk is het niet.

De meeste assembly-programmeurs die ik kon, waren er juist gek op. Ik
vond het ook erg leuk, maar extreem omslachtig, dat wel. Maar zelfs toen
(ca 1985) op de ZX Spectrum kon je al assembly met Forth of een ander
taaltje combineren.

> Overigens heb ik het niet alleen over het uitwisselen van
> bestanden, maar ook over component-technologie, 'network-
> awareness' en dat soort dingen.

Acorn Archimedes, 1987, had al component-technologie, relocatable
modules, met functionaliteit zoals netwerk, scsi drivers, anti-aliasing
en vector rendering, bitmap handling enz enz. Niks nieuws.

>>>- gebruikersvriendelijkheid zal snel ondergeschikt worden aan de
>>> snelheid.
>>
>>Ook dat hoeft niet. Ik vind al die bloated skin rommel niet bijdragen
>>aan gebruikersvriendlijkheid. Windows Media Player is een mooi voorbeeld.
>
> Uiteraard, niet alles is altijd maar goed.

Ik vind kale, saaie, software meestal het prettigste werken.

>>>Zoals je al zegt: de fonts. Leuk voorbeeldje. Kijk nu eens naar
>>>een applicatie uit 1992. Het ziet er werkelijk vreselijk uit.
>>
>>Welk platform?
>
> Vrijwel alles. Misschien dat er wel voorbeelden zijn van goed
> uitziende applicaties, maar dat was toen meer uitzondering dan
> regel.

Op de Acorn zag alles er in 1988 al goed uit, inclusief anti-aliasing.

>>Nooit met Eizo gewerkt? Ooit wel eens een Archimedes met Eizo Monitor
>>gezien naast een windows doos in 1988?
>
> Eizo werk ik regelmatig mee. Ik weet ook wat het spul kost.

Klopt, een monitor was in 88 erg duur, net als een harddisk, en een paar
MB geheugen. Een Archie deed het ook prima met alleen floppy drive :-D.

Overigens waren er ook goedkopere goede monitoren, ADO of zoiets.

>>>De grotere rekenkracht stelt een programmeur ook in staat om te
>>>schrijven in een hogere programmeertaal, zodat hij zich meer op
>>
>>Een hogere programmeertaal wil niet zeggen: resultaat werkt trager.
>
> Nee, maar vaak wel. Maar andersom kan ook natuurlijk: in assembly
> programmeer je liever klein dan dat je meer code gebruikt voor
> een slimmer algorithme.

Soms kan een lus uitrollen extreem veel snelheidswinst geven. De ARM in
combinatie met de memory controller, kon juist sneller worden door hier
en daar de code langer te maken :-D. Het hangt extreem van de eisen af.
Werkt het te traag, zal je toch iets moeten verzinnen.

> Best mogelijk dat je in een hoge taal
> slimmer gaat programmeren en dat het resultaat dus sneller is.

Dat betwijfel ik. Ik kon C programmeurs die pointers maar niet begrepen.
Dat zie ik zo snel niet gebeuren bij een assembly programmeur :-D. Ook
de beruchte bufferoverflow, ik vermoed dat een assemblyprogrammeur toch
meer kaas gegeten heeft van dat soort problemen.

>>programmeren moet nog steeds gebeuren, en nog steeds lowlevel. Nog
>>steeds een bestand openen, kijken of het lukt, schrijven, lukt dat,
>>sluiten, lukt dat enz.
>
> Klopt, maar tegenwoordig stuur je geen printers meer direct aan,
> schrijf je niet naar het videogeheugen, zit tcp/ip keurig in het
> OS, enz, enz.

Dat was met de meeste dingen ook vroeger al zo, of ik heb een bijzonder
OS gebruikt :-D. Videogeheugen direct aansturen was noodzakelijk om
snelheidswinst te behalen, meestal niet voor normaal gebruik.

>>Andere vergissing die je maakt, veel dingen moeten nog steeds efficient.
>>Twintig jaar terug was een bestand van 1 MB groot, nu is een bestand van
>>een paar gigabyte normaal. En als je niet efficient programmeerd, dan
>>loop je tegen problemen op als je met dergelijke bestanden omgaat.
>
> Klopt, ik zeg ook niet dat je nu dom mag programmeren, of dat
> alles zomaar werkt als je er maar genoeg CPU of RAM tegenaan
> smijt. Ik zeg alleen dat je nu makkelijker kunt kiezen voor
> features die rekenkracht vereisen.

Klopt, maar de eisen liggen ook veel hoger. Grotere bestanden,
compressietechnieken, XML parsing, skinnen, geluidseffectjes en
animaties. De hoeveelheid data die verwerkt moet worden is vele malen
groter, dus mag je eisen stellen aan RAM en CPU power.