www.mikrocontroller.net

Forum: Offtopic Seti auf AVR ?


Autor: Marko (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: inoffizieller WM-Rahul (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: D. W. (dave) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: D. W. (dave) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

:)

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
interessanter wärs seti-zeugs auf die graka auszulagern ;)

73

Autor: inoffizieller WM-Rahul (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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...

Autor: D. W. (dave) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Markus K. (markus-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: mr.chip (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Ronny (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Oliver Rother (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Klopapier (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@inoffizieller WM-Rahul

Denke nochmal genau über das von dir geschriebene nach! Kann nicht
wirklich dein Ernst sein, oder?

Autor: inoffizieller WM-Rahul (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Doch!

Autor: D. W. (dave) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Oliver Rother (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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 ;-)

Autor: D. W. (dave) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn, dann nen 4-bit Controller oder gleich mit Logik-ICs, gell :)

Autor: Marko (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Thomas Kropf (thomas_k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also ich find die Idee echt geil. Wenn jemand das umsetzen würde käme
das sicher auf /.

Autor: Oliver Rother (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Oliver Rother (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail, Yahoo oder Facebook? Keine Anmeldung erforderlich!
Mit Google-Account einloggen | Mit Yahoo-Account einloggen | Mit Facebook-Account einloggen
Noch kein Account? Hier anmelden.