Vorige aflevering | Search TidBITS | TidBITS Homepage | Volgende aflevering

TidBITS#472/22-Mar-99

Hoe snel is een Power Mac G3? In ons hoofdartikel mijmert Rick Holzgrafe over snelheid en toont ons een eenvoudig programma waarmee hij 20 jaar lang werkte op verschillende computers. Kijk hoe een G3 is in vergelijking met een Cray Y-MP! Verder onderzoekt Adam deze week de nieuwe e-mail-lijstkoppen die je bovenaan TidBITS en TidBITS Talk ziet. In het Nieuws: Apple publiceert de Mac OS X Server en een openbare beta van QuickTime voor Java en kondigt aan dat ze meedoen aan de open source zegetocht met Darwin.

Onderwerpen:

Copyright 1999 TidBITS Electronic Publishing. All rights reserved.
Information: <info@tidbits.com> Comments: <editors@tidbits.com>


Je kunt je gratis abonneren op de Nederlandse afleveringen van TidBITS door een (blanco) mailtje te sturen naar: tidbits-nl-on@tidbits.com. Je krijgt deze dan per e-mail toegestuurd.
Om je abonnement op te zeggen, kun je een mailtje sturen naar: tidbits-nl-off@tidbits.com.

De Nederlandse editie van TidBITS is een letterlijke vertaling van de oorspronkelijke Engelse versie. Daarom is het mogelijk dat een deel van de inhoud niet geldt in bepaalde landen buiten de USA.


Deze editie van TidBITS werd gedeeltelijk gesponsord door:


Dit nummer werd uit het Engels vertaald door:

Verder werkten mee:


MailBITS/22-Mar-99

Vertaling: [MSH].

Apple Maakt Darwin Open Source Project Bekend -- Vorige week annonceerde Apple zijn plannen om de broncode betreffende principes van de Mac OS X Server beschikbaar te stellen via een open source initiatief, genaamd Darwin. Ontwikkelaars die instemmen met Apple's Public Source Licentie kunnen zich bij Apple registreren om toegang te krijgen tot de source-code, die zal inhouden de verbeteringen van Apple tot de Mach 2.5 microkernel in de Mac OS X Server plus meerdere Apple technologieën zoals AppleTalk, het HFS Plus bestandssysteem en de nieuwe NetInfo gedistribueerde database. Apple zegt van plan te zijn additionele software bij te sluiten in zijn open source aanbiedingen, maar verwacht niet source-code te vinden voor Apple toptechnologieën (zoals het huidige Mac OS, QuickTime, WebObjects, of de NeXT application layer) - uitgegeven als open source. Source code van Darwin zou begin April voor ontwikkelaars beschikbaar zijn. Het valt nog te bezien of Darwin echt nuttig zal zijn voor ontwikkelaars, of dat Apple alleen maar de open source hit aanduidt. Zie TidBITS Talk voor bespreking van het onderwerp.

<http://www.opensource.org/>
<http://www.apple.com/darwin/>
<http://www.publicsource.apple.com/apsl.html>
<http://db.tidbits.com/getbits.acgi?tlkthrd=629>

Mac OS X Server Leverbaar -- Vorige week leverde Apple de Mac OS X Server uit, een nieuw op Unix gebaseerd systeem voor gebruik bij hoogwaardige servers. Vroeger als codenaam Rhapsody voerend, biedt Mac OS X Server de populaire Apache Web server, Apple's WebObjects, de mogelijkheid om nieuwere Mac modellen op te starten op afstand door middel van netBoot, een krachtige Java virtuele machine, netwerkdiensten zoals DNS en Apple File Protocol, Web-gebaseeerde administratie en een consistente Mac-achtige gebruikers-interface. (zie "Nieuwe iMacs, Nieuwe G3s, en Mac OS X Server" in TidBITS-462 voor meer informatie) Mac OS X Server laat BSD Unix 4.4 werken bovenop de Mach 2.5 microkernel (die tesamen preemptive multitasking en beschermd geheugen bieden), plus applicatie technologieën, die origineel van NeXT afkomstig waren. Gezegd wordt dat Mac OS X Server de Blue Box applicatielaag bevat, waardoor Mac OS X Server de standaard Apple applicaties kan verwerken. Alle berichten zeggen dat de Blue Box niet bedoeld is om Mac OS X Server te laten werken als een werkstation of om actuele Mac OS server software te laten lopen. Ondersteuning voor ontwikkelaars van Mac OS X Server groeit; meerdere ondernemingen hebben reeds plannen voor de Mac OS X Server aangekondigd en zeker zullen er nog meerdere volgen. Apple heeft de Mac OS X Server agressief geprijsd op $499, met ongelimiteerde licentie voor cliënten; ook verkoopt Apple op 400 MHz G3-gebaseerde servers met Mac OS X Server reeds geïnstalleerd, beginnend bij $4.999 (waarvan Apple zegt dat dit het snelste Apache serverplatform is, verkrijgbaar onder de $5000). [GD]

<http://www.apple.com/macosx/server/>
<http://www.apache.org/>
<http://db.tidbits.com/getbits.acgi?tbart=05235>

QuickTime Krijgt een Cafeïne Oppepper --Heden annonceerde Apple de openbare beta uitgave van QuickTime voor Java, dat de reikwijdte van QuickTime uitbreidt tot iedere applicatie, die in Java geschreven is, zowel in het Mac OS als Windows. Momenteel alleen interessant voor ontwikkelaars, maar Java ondersteuning is een belangrijke stap voor Apple betreffende universele bruikbaarheid van QuickTime. Nodig voor QuickTime voor Java is dat je eerst MRJ 2.1 installeert (of JRE 1.1.x of 1.2 indien je het Windows Java Runtime Environment gebruikt) en QuickTime 3.0.2 - zie de QuickTime voor Java installatie-pagina betreffende links. [ACE]

<http://www.apple.com/quicktime/qtjava/>


Al die kopteksten van verzendlijsten uitgelegd

door Adam C. Engst <ace@tidbits.com>. Vertaling: [KD], [IdM], [LmR] & [JS].

Wanneer ik aan nieuwelingen uitleg hoe e-mail werkt, noem ik de e-mail-kopteksten "de brij bovenaan", daar ze niet eenvoudig voor de mens te verteren zijn. Kopteksten zijn regels tekst die aan een e-mail voorafgaan; ze bevatten beschrijvende informatie over de boodschap in plaats van de boodschap zelf. U bent vermoedelijk bekend met de voornaamste voor de mens leesbare kopteksten, zoals Datum, Van, Onderwerp, en Aan, maar u wenst vermoedelijk dat sommige, meer onontcijferbare kopteksten, zoals Message-Id, Content-Type, of Received, die samen een ondoordringbare wirwar kunnen vormen, nooit gezien te hebben. Deze geheimzinnige kopteksten zijn bedoeld om begrepen te worden door e-mailprogramma's, en niet door mensen, daarom verbergen e-mailprogramma's vaak die kopteksten die hoog scoren op de schaal van techneutenjargon.

Hoe dan ook, het zou u opgevallen kunnen zijn dat TidBITS en TidBITS Talk nieuwe en ongebruikelijke e-mail-kopteksten hebben doen ontspruiten sedert het begin van 1999. De meeste van die kopteksten, die ik gezamelijk de "verzendlijst-kopteksten" noem, zijn aanstaande Internet standaarden. Deze kopteksten zijn voor de mens leesbaar en voorzien in bruikbare informatie voor ingeschrevenen op een verzendlijst, maar ze zijn bedoeld om begrepen te worden door e-mailprogramma's, zodat die de e-mailgebruikers kunnen helpen met het beter beheren van hun verzendlijst inschrijvingen.

<http://www.ietf.org/rfc/rfc2369.txt>
<http://www.ietf.org/internet-drafts/draft-chandhok-listid-03.txt>

Kop op -- Omdat de verzendlijst-kopteksten gestandaardiseerd zijn kunnen e-mailprogramma's nu beginnen aandacht aan hen te besteden. Aanvangs-ondersteuning van luie ontwikkelaars zou zijn deze kopteksten te verbergen, daar ze een aantal regels in iedere verzendlijst e-mail in beslag nemen. Een betere oplossing zou zijn een Opzeggen menu item tijdens het bekijken van berichten die verzendlijst-kopteksten bevatten. Nog bruikbaarder zou een interface zijn, die behulpzaam is bij het in kaart brengen van uw verzendlijst-inschrijvingen, wat u in staat stelt om één of al uw verzendlijst-inschrijvingen met een druk op de knop op te zeggen en de verzendlijst-berichten automatisch te filteren. Zodra dat niveau van functionaliteit beschikbaar is kunnen de verzendlijst-kopteksten verborgen worden, omdat het e-mailprogramma hun functionaliteit heeft overgenomen.

Daarnaast, totdat e-mailprogramma's verzendlijst-kopteksten rechtstreeks ondersteunen, kunnen de kopteksten het makkelijker maken voor gewone mensen om hun verzendlijst-inschrijvingen te beheren. Ik beschrijf al de verzendlijst-kopteksten die we bij TidBITS gebruiken hieronder, omdat de verzendlijst-kopteksten URL's bevatten. Het klikken van de van toepassing zijnde URL kan u uitschrijven van de verzendlijst, hulp verschaffen, of een e-mail versturen naar de eigenaar van de verzendlijst. Verder, als u aan iemand instructies wilt versturen over hoe in te schrijven op de verzendlijst, kunt u aan deze persoon de List-Subscribe koptekst-URL toesturen.

De headers op een rijtje -- Laten we nu eens kijken naar de list headers die we gebruiken in TidBITS en waarom andere lijsten er wel of geen gebruik van zouden willen maken. Merk op dat de volgorde willekeurig is - de volgorde die we kozen is enkel gebaseerd op regellengte, voor een gemakkelijke visuele voorstelling.

List-URL: <http://www.tidbits.com/>
List-Archive: <http://www.tidbits.com/search/>
List-Subscribe: <mailto:tidbits-on@tidbits.com>
List-Unsubscribe: <mailto:tidbits-off@tidbits.com>
List-Help: <http://www.tidbits.com/about/list.html>
List-Owner: <mailto:editors@tidbits.com> (TidBITS Editors)
List-Software: "ListSTAR v1.2 by StarNine Technologies, Inc."
List-Id: "TidBITS Setext Distribution List" <setext.tidbits.tidbits.com>
List-Post: <mailto:tidbits-talk@tidbits.com> (Discussions on TidBITS Talk)

De volgende header verschijnt ook in TidBITS Talk:

List-Digest: <mailto:tidbits-talk-digest@tidbits.com>

Wie Zou List Headers Moeten Gebruiken? Ik zal eerlijk zijn: een belangrijke reden om list headers te adopteren voor TidBITS en TidBITS Talk is dat we een aantal mensen kennen die betrokken zijn bij het standaardisatieproces. Deze mensen hebben ons ervan overtuigd list headers te ondersteunen, en hebben vragen beantwoord die ik had toen ik de meest toepasselijke set probeerde te maken voor TidBITS en TidBITS Talk. Maar los van onze specifieke situatie zijn er vier groepen mensen die aandacht zouden moeten schenken aan list headers: zij die een mailing list draaien, zij die e-mailprogramma's schrijven, ontwikkelaars van mailing list programma's, en als laatste, zij die inschrijven op een mailing list.

Ik raad iedereen aan die een mailing list onderhoudt de juiste list headers toe te voegen. Ze zijn niet ingewikkeld om te maken, en de meeste mailing list programma's laten je speciale headers toevoegen. Mijn hoop is dat de tijd en moeite die ik steek in het maken van list headers terugkomt in een vermindering van de hoeveelheid tijd die ik steek in het ondersteunen van mensen die inschrijven op onze mailing lists.

Ontwikkelaars van e-mailprogramma's zouden moeten nadenken over wat de beste manier is om de list headers intern te ondersteunen. Ik heb een vroege versie gezien van een programma dat de mogelijkheid biedt je mailing list inschrijvingen te beheren gebaseerd op de list headers, en het is duidelijk dat het goed werkt. Bekijk het op deze manier: totdat de ondersteuning van list headers alom aanwezig is, kunnen e-mailprogramma's het pontificaal op hun lijst met ondersteunde zaken zetten.

Ontwikkelaars die beheersprogramma's maken voor mailing lists hoeven wellicht niet veel te doen, aangezien bijzondere headers al ondersteund worden door vrijwel alle programma's op dit gebied. Deze programma's zouden het maken van list headers gemakkelijker kunnen maken, wat de acceptatiegraad van list headers zal verhogen.

Vanuit het standpunt van de individuele gebruiker zou ik slechts willen suggereren dat je eens kijkt naar list headers, en onthoudt dat ze bestaan. Als je wilt zoeken naar informatie in een bericht dat je al weggegooid hebt, kijk dan naar de List-Archive header, of als je een abonnement wilt opzeggen, gebruik de URL in de List-Unsubscribe header.

Zoals we de afgelopen jaren gezien hebben, hebben gebruikers moeite met de interactie met mailing list programma's, en alles wat dat proces kan verbeteren dient de gehele Internet gemeenschap.


Power Macintosh G3: De Cannonball Express

door Rick Holzgrafe <rick@kagi.com>. Vertaling: [DPF], [MK] & [JV].

De Cannonball Express was volgens overlevering de trein die zo snel was dat je drie mensen nodig had om te zeggen: "Hier komtie," "Daar istie" en "Daar gaatie weer." Computers zijn ook snel, maar een belangrijk verschil met treinen is dat de meesten zichzelf niet voortbewegen. Wat zorgt ervoor dat een computer snel is, en hoeveel effect heeft het ontwerp van software? Hoeveel sneller zijn de computers van vandaag de dag dan die van gisteren? Ik heb me recentelijk weer eens met een paar van deze vragen bezig gehouden, en dat was eigenlijk nogal een nostalgische trip.

Terug in het Stenen Tijdperk -- Twintig jaar geleden leerde ik mezelf programmeren en had ik 's avonds en in het weekend toegang tot een DEC PDP-11/60 minicomputer. Dit kreng was groter dan een wasmachine, en gedurende werkdagen moest ik het delen met twee dozijn andere techneuten en ingenieurs. Ik had een woordraadsel gevonden in een tijdschrift en het leek me leuk om een programma voor de PDP te schrijven om het raadsel op te lossen. Het raadsel was als volgt.

Gegeven zijn een bepaalde zin en een blad ruitjespapier, en schrijf die zin vervolgens op dat papier volgens de volgende regels:

  1. Schrijf één letter per vierkantje op het uitjespapier, net alsof je een kruiswoordraadsel invult. Let niet op hoofd/gewone letters of dingen die zich niet in het alfabet bevinden. De zin "N. 1st Street" is hiermee identiek aan "NSTSTREET".

  2. De eerste letter van de zin mag zich in een willekeurig vierkant bevinden.

  3. Stop elke volgende letter van de zin in een vierkant ernaast. "Ernaast" betekent hier willekeurig welke van de acht aangrenzende vierkanten, erboven, eronder, links, rechts of diagonaal. Het is toegestaan een vierkant opnieuw te gebruiken als het ernaast zit en al de letter bevat die je nodig hebt. Als dit niet zo is moet je een leeg vierkant gebruiken. Je mag niet hetzelfde vierkant twee maal achter elkaar gebruiken - dus een "pas op de plaats" voor dubbele letters is niet toegestaan.

Het doel is een zin te schrijven in een zo klein mogelijke rechthoek (een subtiel verschil: het gaat niet om de kleinste hoeveelheid vierkanten). Om een score aan je oplossing te verbinden moet je de kleinst mogelijke rechthoek tekenen die alle letters van de zin bevat. Lege vierkantjes binnen dit gebied zijn toegestaan, maar je moet ze wel meetellen.

Snap je? Tongbrekers zijn het leukste omdat ze vele mogelijkheden bieden om hele stukken opnieuw te gebruiken. De 37 letters in "Peter Piper picked a peck of pickled peppers" passen in een rechthoek van 3 bij 5, zoals hieronder (kijk hiernaar in een niet-proportioneel lettertype):

   OFIPT
   KCPER
   LEDAS

Ik wist toen wel dat computers "snel" waren maar ik had er geen idee van hoe snel. Het antwoord bleek uiteindelijk "niet erg" te zijn. Ik schreef een programma om deze raadsels op te lossen en noemde het Piper naar bovengenoemde zin. Ik zette Piper aan het werk op een gemiddelde zin op vrijdagavond, en kwam 's maandags terug om te ontdekken dat het nog steeds bezig was. Het had verschillende niet-optimale oplossingen gevonden maar was nog niet klaar. Veel te langzaam - ik vond zelf op papier een betere in ongeveer een half uur.

Waarom duurde het zo lang? Piper was in feite een "dommekracht". Het probeerde iedere mogelijke oplossing uit, één voor één. Het probleem is dat er gewoon te veel mogelijke oplossingen zijn. Hoeveel precies is afhankelijk van de zin, maar voor een willekeurige normale zin is het aantal astronomisch groot. Ik realiseerde me voor de eerste keer dat "snel" niet altijd "snel genoeg" is. Vandaag de dag is dat misschien duidelijk, omdat we nu allemaal computers gebruiken en er niet van houden om op ze te moeten wachten. In 1979 echter was die PDP-11 pas de tweede computer die ik ooit had gezien!

Welk gedeelte van snel begrijp je niet? Ik zag in dat ik Piper sneller zou moeten maken. Er zijn in principe twee manieren om een programma te versnellen. Plan A is het vinden van een betere strategie om het probleem op te lossen, maar die heb ik in twintig jaar nog niet gevonden. Rest ons plan B, de klassieke oplossing van de efficiëntie-deskundige: elimineer de overbodige stappen. Piper zocht bijvoorbeeld elke mogelijke oplossing uit en berekende daarna de rechthoek die deze in beslag zou nemen. Dat uitzoeken gebeurde letter voor letter, dus veranderde ik Piper zo, dat hij het benodigde oppervlak bekeek na elke toegevoegde letter. Als door het plaatsen van een letter de opppervlakte groter werd dan bij de tot dan toe beste oplossing, kon Piper die oplossing (en alle andere oplossingen die op dezelfde manier begonnen) verder laten voor wat hij was. Dit bespaarde een enorme hoeveelheid werk en verhoogde Piper's snelheid aanzienlijk. Het vinden van slimme manieren om het oppervlak bij te houden van een zich ontwikkelende oplossing hielp ook erg, omdat dat minder tijd kostte dan het steeds na elke letter opnieuw berekenen ervan. Ik vond ook een manier om snel de minimale afmetingen van een rechthoek voor de uiteindelijke oplossing te berekenen: ik wist wel niet zeker of de beste oplossing zó klein zou zijn, maar wel dat hij niet kleiner kon zijn dan dat minimum. Als Piper geluk had, en een oplossing vond die net zo klein was als dat theoretische minimum, kon hij onmiddellijk stoppen. Anders zou hij tevergeefs naar een betere oplossing dan de al gevonden best mogelijke blijven zoeken.

Tenslotte werd Piper slim genoeg om die oorspronkelijke zin binnen redelijk korte tijd in een rechthoek te zetten. Maar de heilige graal kreeg ik maar niet te pakken: ik wilde een oplossing voor "How much wood would a woodchuck chuck if a woodchuck could chuck wood?" Dit was teveel voor die PDP (en, héél misschien, voor mijn capaciteiten). Mijn ideeën voor het sneller maken van Piper waren uitgeput en het programma had nog steeds meer dan een weekend nodig voor het vinden van de beste oplossing. Maar als ik Piper niet kon verbeteren, dan kon ik toch op zijn minst hopen het ooit op een snellere computer te draaien.

Het Grote IJzer -- Mensen denken vaak dat de snelheid van een computer alleen wordt bepaald door de processorsnelheid, maar er zijn vele factoren die van belang zijn voor de uiteindelijke prestaties. Virtueel geheugen stelt je in staat om met grotere datasets of aan meer problemen tegelijk te werken, maar het is wel langzaam, dus het bijplaatsen van geheugenchips helpt, doordat minder vaak een beroep gedaan hoeft te worden op het virtueel geheugen. Snellere schijven en I/O-bussen halen data sneller binnen en schrijven het sneller weg. RAM-disks en het cachen van schijfgeheugen kunnen tot op zekere hoogte langzame schijfoperaties vervangen door lees- en schrijfbewerkingen in het bliksemsnelle RAM. Instructie- en data-caches in speciaal supersnel RAM leveren in sommige programma's grote verbeteringen op. Goed geprogrammeerde besturingssystemen en toolboxen kunnen sneller zijn dan hun wat zwakkere evenknieën.

Maar dit heeft allemaal niet zoveel betekenis voor Piper. Piper heeft altijd maar een kleine hoeveelheid data heen en weer geschoven, leest en schrijft niet naar de schijf als hij eenmaal bezig is, en kent ook verder niet veel I/O-acties. Met zijn beperkte hoeveelheid code en data kan Piper wel goed gebruik maken van data- en instructie-caches, maar het programma is toch het meest gebaat bij "snellere hamsters" - een snellere processor om de wieltjes vlugger te laten draaien.

In de loop der jaren heb ik verschillende versies van Piper op mijn eerste Macs gedraaid, maar in het midden van de jaren '80 werkte ik voor Apple Computer en had toegang tot een machine waar programmeurs van dromen: Apple's $15 miljoen kostende Cray Y-MP supercomputer, een van de vijfentwintig die er in de hele wereld waren en waarschijnlijk de snelste computer die in die tijd bestond. Ik had het idee dat de Cray korte metten zou maken met Piper. Maar de Cray was niet erg op dit probleem toegesneden. Hij spoot werkelijk door parallel uitgevoerde drijvende-kommaberekeningen, ongeveer zo snel als de Cannonball Express, maar Piper was een erg lineair, niet-wiskundig probleem. Piper gebruikte maar een van de vier processoren van de Cray en deed geen beroep op het soort bewerkingen waarin de Cray uitblonk. Piper was geen eerlijke test voor de kracht van de Cray, maar dat nam niet weg dat de Cray toch de snelste machine was die ik ooit had gebruikt. De Cray slaagde waar al zijn voorgangers (die PDP, mijn Mac Plus, mijn Mac II) hadden gefaald. Hij loste "woodchuck" op in minder dan een dag, namelijk in maar ongeveer 20 uur. Ik stond perplex - 20 uur?! Ik had er geen idee van dat "woodchuck" zo'n groot probleem was!

Young Whippersnappers -- Ik heb Piper voor vele jaren opgeborgen, maar onlangs begon ik me af te vragen wat de vergelijking is tussen een moderne desktop en die ouwe minicomputers en mainframes. Ik herschreef Piper uit het geheugen, en liet het los op mijn nieuwe 400 MHz ice-blue Power Macintosh G3 met "woodchuck." Het resultaat ligt lager. Piper drukt eerst de zin terug af, en geeft dan oplossingen en de verstreken tijd wanneer het resultaten vindt. Elke oplossing is de beste die totdantoe gevonden werd, met als eindresultaat de allerbeste oplossing. De tijd is uitgedrukt in seconden vanaf het starten van het proces; de laatste tijd is de totale tijd dat de berekening in beslag nam. (Jammer genoeg ligt de beste oplossing voor "woodchuck" hoger dan het door Piper berekende minimum, zodat Piper nog even doorging na het vinden van de beste oplossing.)

Hier volgen de resultaten. Sommige van de tussenoplossingen zijn niet vermeld om plaats te besparen, maar je kan zien dat Piper telkens kleinere oplossingen vindt. Uiteindelijk worden de 57 letters in "woodchuck" samengepakt in een vierkant van 4 op 4. Bekijk eens de totale tijd die Piper nodig had en de tijd om de beste oplossing te vinden:

How much wood would a woodchuck chuck if a woodchuck could chuck wood?

0 seconds:
      ULD  ADLU
   HDOAIUCOHWUHOD
   UCOWFKHDOMCWOW
    K   WO

1 seconds:
   DLIFADLU
   UCKOHWUHOD
   OHDWOMCWOW

2 seconds:
      ULCHC
   HWUHODKUK
   OMCWOWAFI

7 seconds:
   HWUHOW
   OMCWOD
   IKAUCW
    FLDHK

9 seconds:
   HWUH
   OMCW
   LUOK
   HDOI
   CWAF

65 seconds:
   HWM
   OUC
   IKH
   FWC
   ADO
   LUO

67 seconds:
   HWMU
   OOCH
   UDWK
   LAFI

Total run time: 107 seconds

Daar is het dan: net iets over een minuut om de beste oplossing te vinden, en onder twee minuten om het programma te beëindigen. Twee minuten! Exit het bakbeest van de jaren 80. Mijn nieuwe G3 Mac vond "woodchuck" meer dan 600 maal sneller (en 5000 keer goedkoper) dan de 15 megabuck kostende Cray. (Voor een meer realistische vergelijking, kijk eens naar de beschrijving van het UCLA Project Appleseed.)

<http://www.apple.com/education/hed/aua0101/appleseed/>

Als je Pipers snelheid op jouw Mac wil testen, ik heb de broncode in het Public Domain geplaatst; het is een pakje van 40K.

<ftp://ftp.tidbits.com/pub/tidbits/misc/piper.hqx>

De toekomst -- Wat staat er ons nog te wachten? 400 MHz ziet er al een beetje beperkt uit. Het is het beste dat Apple vandaag te bieden heeft, maar ik heb informatie gezien over versnellers van derden en overklokken, waarin beweerd wordt dat 550 MHz gehaald wordt. Er worden 1 GHz (1000 MHz) chips voorspeld voor de nabije toekomst. Bussen worden sneller en caches bevatten meer data in minder ruimte en verhuizen naar de processorchip voor nog meer snelheid. (Klein is snel. Wist je dat de lichtsnelheid een belangrijke limiet is in modern computerdesign? Hoe dichter de componenten bij elkaar zitten, hoe sneller ze elkaar informatie kunnen doorspelen.)

En naar analogie met de ouwe Cray zie je stilletjesaan multiprocessor desktops opduiken. Zij benaderen het probleem door verschillende processoren aan verschillende delen van het probleem te laten werken. Hoewel ik nooit probeerde de extra processors van de Cray te gebruiken, heb ik de laatste tijd een beetje zitten nadenken. Piper hoeft niet absoluut lineair te zijn. Ik durf er op wedden dat ik op een systeem met 8 processoren, Piper bijna in een achtste van de tijd zou kunnen laten werken als met één enkele processor.

Are you ready?

Here she comes -
    Here she is -
        There she GOES!


Niet-winstgevende en niet-commerciële publicaties en Websites mogen artikels overnemen of een HTML link maken als de bron duidelijk en volledig vermeld wordt. Anderen gelieve ons te contacteren. We garanderen de precisie van de artikels niet. Caveat lector. Publicatie-, product- en firmanamen kunnen gedeponeerde merken zijn van hun ondernemingen.

Vorige aflevering | Search TidBITS | TidBITS Homepage | Volgende aflevering