Hi Forum, ich hab da eine, vermutlich, doofe Frage. Also die ATMegas bringen ja von der Rechenleistung her bis zu 16 MIPS, mal abgesehen von so Kuriositäten wie Overclocking etc. Währe es da nicht denkbar so kleine Rechengeschichten wie das SET oder BOINC auf so nen kleinen Knubbel auszulagern? Ich mein, was braucht man schon, RAM, evtl. SRAM, parallel dran für flotten Zugriff und ne Schnittstelle wo neue Daten drauf und Ergebnisse runter. Ne Status-LED und ne Batterie bzw. kleines Steckernetzteil. Klar hat mein P4 an so ner UNIT ne ganze Weile zu rechnen, aber der hat ja noch einiges anderes zu tun was ihn bremst, Grafikkarte, Schnittstellen, Soundkarte, Laufwerkscontroller usw. usw. Der AVR hätt ja ausser rechnen sonst nix zu tun. Hat von Euch jemand nen Plan wie die Suchalgorythmen aussehen, bzw. wie komplex die sind, oder hat das gar schon versucht?
AFAIK ist für SETI@Home float-Berechnung nötig. Das unterstützt der AVR nur in Software... So viel, wie du aufführst, hat der P4 gar nicht zutun. Das übernehmen alles irgendwelche anderen Prozessoren.
Mit nem AVR brauchst du garnicht anfangen, er hat zwar 16 "MIPS", aber MIPS sagen erstens garnichts über die Leistungsfähigkeit aus, zweitens ist das echt wenig :) Nen AVR ist ein 8bit-Controller ohne FPU mit Harvard-Architektur. Viel wirste damit nicht anstellen können. Versuch lieber mal etwas mit nem 32bit-Controller, wie ARM7 oder andre ARM. So viel hat nen P4 auch nicht mit seinen Schnittstellen zu tun.
Nachtrag: 1. der inaktive Fußballer war schneller. 2. wenn du das auf nem ATMega zustande bringst, dann stelle ich gerne einen m64 oder m128 dazu ab, erweitere ihn mit 64k oder mehr RAM und rüste ihn mit ner rj45 aus und lasse so nen Suchprogramm drauf laufen. Mindestens 6 Monate. :)
@David: Die Architektur hat in diesem Fall doch nichts mit der Leitungsfähigkeit zutun, oder irre ich mich da (mal wieder)? Wenn man einen Controller mit FPU benutzt, könnte es was werden. Die MIPS (bzw. deren Verhältnis zur Taktfrequenz) des AVR zeigt einfach nur, dass sie über keinen Taktteiler, wie 8051 oder PICmicro, (mehr) verfügen. Für SETI etc braucht man eher FLOPS...
Mit der Harvard-Architektur meinte ich eigentlich, dass man nicht so einfach externen RAM (bis auf XMEM-Interface) und man kann auch nicht wie beim ARM7 mal schnell den Programmcode in den RAM kopieren, um doppelt so schnell arbeiten zu können. Soll doch mal ne USB-Version vom AVR geben, der mit 48MHz aussem Ram läuft, also könnte man so mehr übertakten. Der Flash ist bei Atmel doch so lahm. Ich muss zugeben, ich kenn SETI nicht genug, aber mit ner Neumann-Architektur könnte man auch Programmteile im Ram ausführen, falls sie zu groß für den Flash sind.
@David: Die AVRs sind auf etwa 20MHz ausgelegt und dafür ist das Flash schnell genug. Es würde nichts bringen, wenn Du den Code ins RAM kopieren könntest. Beim ARM7 ist das was anderes: Für 60MHz bräuchte man 15ns Flashspeicher - und das gibts wohl nicht. Deswegen wird dort mit einigen Tricks gearbeitet, die aber wohl nicht immer so richtig greifen. Deswegen bringt Code ins RAM kopieren einen Geschwindigkeitsvorteil. Markus
> Die AVRs sind auf etwa 20MHz ausgelegt und dafür ist das Flash > schnell genug. Jein. Die begrenzende Limite bei den AVRs ist ja gerade der Flash-Speicher. Ich halte die Idee mit dem Auslagern von wissenschaftlichen Berechnungen nicht für sinnvoll. Die Architektur des AVR ist definitiv ungeeignet für grosse numerische Berechnungen. Er kann nämlich die zwei wichtigsten Dinge dafür nicht: Mit grossen Zahlen umgehen und mit diesen rechnen.
Also zunächst mal: Der AVR ist so ziemlich der effektivste 8-Bitter den ich kenne,mehr Arbeitsschritte pro MHz sind schwer zu finden.Aber wie gesagt handelt es sich um einen 8-Bitter,alle Operationen die mehr als 8 Bit benötigen (Zahlen grösser 255) können nicht mit der vollen Effektivität bearbeitet werden.Soll er nun mit 16 Bits rechnen,dann ist die Geschwindigkeit bestenfalls schon nur noch halb so gross.Und wenn´s um Fließkommazahlen geht,ist sowieso alles verloren. Das,wofür der AVR gedacht ist,erledigt er sicherlich effektiver als ein P4,er benötigt weniger MHz für die selbe MIPS-Zahl wie der P4 (ich freu mich hier schon auf die Diskussion).Allerdings bezeichnet MIPS grob gesagt nur den Befehlsdurchsatz.Und da der P4 gerade zum Rechnen deutlich mehr Befehle (und auch Co-Prozessor-Einheiten für Fließkomma-Berechnungen) besitzt,ist der Vergleich eigentlich hinfällig.Und die Takte die der P4 bei einigen Befehlen mehr braucht,kompensiert er locker mit seiner 2xHundertfach höheren Taktfrequenz.Und Pipeline-Effekte (mehrere unabhängige Berechnungen gleichzeit,usw) sind beim AVR auch nich drin. Interessant für Fließkomma-Beschleunigung wären dann eher moderne Grafik-Chips.Oder bei Fixed-Point Arithmetik vielleicht auch ein (oder mehrere) DSP(s).Dann wäre aber wieder die Datenübertragung zwischen PC und Rechenbox limitierend. Ein Zwischenschritt zwischen AVR und ARM wären vielleicht die Infineon XC16x-Controller(16-Bitter).Diese besitzen eine 5-stufige Pipeline für schnellere Befehlsabarbeitung (u.a. ist in manchen Situationen ein Sprungbefehl in 0-Takten möglich) und eine MAC (multiply&addition) vorhanden,ähnlich wie in DSPs.Inwiefern letztere von C-Compilern korrekt angesprochen steht auf einem anderen Blatt.
Ich weiss ja nicht, ob bei Euch schon wieder April ist, aber abgesehen von der Unmoeglichkeit, innerhalb des Verfallsdatums der Workunit mit den FFTs fertig zu werden, ist jede Betrachtung einer Plattform, fuer die es keine offizielle BOINC-Software gibt rein akademisch. Das sind keine "Suchalgorithmen", die man mal eben selbst portiert. Und wenn selbst wwenn Ihr das schafft, koennt ihr bis zum thermischen Ende des Universums Workunits rechnen, ohne je ein Result zu bekommen - denn die selbstgetrickte Software wird ja kaum die korrekte Checksumme zurueckliefern. Das ist echt der groesste Kaese seit der Kanzlerwerdung von A. Merkel.
@inoffizieller WM-Rahul Denke nochmal genau über das von dir geschriebene nach! Kann nicht wirklich dein Ernst sein, oder?
@Oliver Du glaubst doch nicht, dass diese Diskussion einen praktischen Sinn verfolgte. Also ich war sicher nicht darauf aus, SETI auf meinen AVRs rennen zu lassen.
@Dave: Nein, das glaube ich natuerlich nicht. Ich wollte lediglich nur die Unmoeglichkeit des Vorhabens von der Softwareseite beleuchten - aber alleine die Idee,das auf 8bit-Rechnern machen zu wollen erscheint mir behandlungsbeduerftig ;-)
Wenn, dann nen 4-bit Controller oder gleich mit Logik-ICs, gell :)
Also ich kann bei mir keine Behandlungsbedürftigkeit festestellen, leider kann ic hda nicht dienen. Ob die Kiste 8 16 oder dann 64 Bit hat ist doch zunächstmal unerheblich. im Endeffekt läufts auf Bits und Bites raus und natürlich auf das Programm und da seh ich den Hund begraben. Das Seti ist ja oben Source, aber im Ernst, das ganze Ding ist dermaßen komplex dusammengepfriemelt aus x Modulen, die mitunter gerade mal 5 Codezeilen lang sind, ich blick da nicht durch ... wenn jemand wüsste in welchem Modul sich die Eigentliche Suchfunktion befindet würd ich mir das schon mal gern anschaun ob das machbar ist ... ich hab aber wo was in dem Code gesehen von FFT, das wirds dann schon eng auf dem AVR ... ich denk es käm aber mal auf n Versuch an, oder?
Gewisse Nebeneffekte durch begrenzten Adressraum hast du hier wohl untern den Tisch fallen lasssen. Lass SETI laufen und sieh dir bloss mal den Workingset an. Und wie weit du mit 64KB RAM kommst.
Also ich find die Idee echt geil. Wenn jemand das umsetzen würde käme das sicher auf /.
Das zentrale Problem ist die FFT (Fast Fourier Transformation), wem das nichts sagt. Dafuer braucht es Rechenleistung, und zwar 32 Bit. Klar kann man das auch auf einem 8 Bit Rechner machen, nur dann dauert eine Workunit zwei Jahre, webei ich mich da nicht auf einen Faktor 10 nach oben festlegen will. Klar ist SETI an sich Open Source. Nur, damit SEIT die Results Deiner Workunits auch annimmt, muss die Checksumme des Paketes stimmen. Es soll ja in der Vergangenheit Versuche gegeben habe, sich durch den Upload gefakter Results Credits zu ergaunern. Von daher muss die Software zumindest von Seti zertifiziert werden, viel Spass dabei.
Der Adressraum ist nicht das Problem, das benoetigte Megabyte kann man auch mit einem AVR adressieren und dann ein Dimm dranloeten. Aber selbst wenn man die Probleamtik, dass man die 32bit-Zahlen irgendwie darstellen und adressieren muss ausser acht laesst, bleibt das Problem der puren Rechenleistung. Es gibt da kaum ertwas ansprucksvolleres als FFT (deshalb macht man das embedded auch nicht solftwaremaessig sondern mit DSPs). Die Workunits haben ein Verfallsdatum von zwei Wochen (?), wenn ihr das in der Zeit schafft...
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.