Zreak

• 08.06.26
• 12:59
• Artikel

@dudelsack: Im All gibt es keine Konvektion oder Wärmeleitung (weil basically keine Atmosphäre), aber Wärmestrahlung gibt es weiterhin.

Wenn du in der Sonne sitzt, wärmt dich das Licht. Gegenstände geben immer Wärme in Form von Licht ab (bei Raumtemperatur im unsichtbaren Infrarot-Bereich, die Sonne ist so heiß, dass sie sichtbares Licht abgibt). Infrarot-Thermometer sind "basically nur Kameras die Infrarot sehen können" und daraus die Temperatur ausrechnen.

Das gesamte Weltall leuchtet mit etwa 4 Kelvin (Kosmische Hintergrundstrahlung) was immer zurecht als "kalt" betrachtet wird. Die Sonne hält einen allerdings im Sonnensystem deutlich Wärmer (außer man ist im Schatten).

Wie viel Energie als Licht abgestrahlt wird, lässt sich übrigens über das Stefan-Boltzmann-Gesetz berechnen.

Wenn man wirklich nah an die Sonne fliegt, wird zum einen das Licht intensiver (näher an der Taschenlampe ist es heller) zum anderen kommen aber tatsächlich auch wieder Effekte wie die Wärmeleitung durch Teilchen aus der Sonnen-Korona zum tragen.

• 08.06.26
• 12:45
• Artikel

@happy_dogshit: Macht man am Boden auch nicht.

• 08.06.26
• 12:44
• Artikel

@Gösser: hauptsächlich Stromkosten: Fast doppelt so viel Solar-Leistung pro Fläche, weil die Atmosphäre und Wolken nicht stören. Rund um die Uhr Solar wenn man den Satelliten richtig positioniert. Solarstrom im All kostet effektiv nur einen kleinen Bruchteil von Strom am Boden. Da der Strompreis bestimmt wie lange man Hardware wirtschaftlich betreiben kann, kann man die Hardware von Tag eins an günstiger Betreiben und sie länger wirtschaftlich nutzen. Wenn die Startpreise ins All mit Starship noch deutlich weiter nach unten verschieben, geht die Rechnung auf.

Außerdem scheint es aktuell leichter zu sein Satelliten genehmigt zu bekommen als ein Rechenzentrum am Boden.

• 08.06.26
• 12:38
• Artikel

@Nunk-Junge: [Citation needed]

Die aktuellen dual GB200 Superchips rechnen mit 40 PetaFlops (sparse, fp4) bei 2,7 kW. Keiner redet von 50 PetaFlops in fp32 oder gar fp64.

• 08.06.26
• 12:32
• Artikel
• +1

@Mitsch79: Ist nicht so ein großes Problem wie die Leute, die nicht nachgerechnet haben gerne glauben. Scott Manley hat ein gutes Video dazu, falls es einen von euch wirklich interessiert: https://www.youtube.com/watch?v=FlQYU3m1e80

• 18.11.25
• 09:29
• Artikel

Not gonna enter the whole shitstorm, aber zum Punkt "Wie soll ein Verrauschen von Parametern sicherstellen "Vorhersagen physikalisch realistisch" zu halten?!", dass ist tatsächlich einer der wichtigsten Schritte bei sowas. Das hilft dem Modell die Vorhersage auf eine breite Basis an Informationen zu begründen. Stell dir vor zufälligerweise ist in den Wetterdaten immer Freitag der 13. wenn was schlimmes passiert. Wenn du die Daten nicht verrauschst sorgt das dafür, dass das Netzwerk nur "Freitag der 13." lernt, nicht was der eigentliche Auslöser ist. Viele Techniken wie Dropout, Bayesian Neural Networks, Restricted Boltzmann Machines usw. basieren genau darauf.

• 28.08.25
• 09:20
• Artikel
• +2

@DRMfan^^: Du meinst sowas wie https://github.com/ROCm/HIPIFY ? Problem ist eher, dass GPGPU Code halt meistens sehr low level ist, z.B. via Nvidia Cutlass auf die Tensor Cores zugreift oder halt einfach auf bestimmt Shared memory sizes und Instruction latencies/throughputs getuned ist. Das macht portieren zwar vielleicht nicht unmöglich, schnell läuft er dann halt aber nicht.

• 16.01.24
• 14:55
• Artikel
• +4

@Fanta4all: Licht überträgt tatsächlich Impuls (siehe z.B. Breakthrough Starshot). Die Idee hierbei ist aber viel mehr, dass Teile an der Oberfläche verdampfen und sich mit hoher Geschwindigkeit vom getroffen Objekt wegbewegen (praktisch wie bei einem Raketentriebwerk). Leuchtet man den Schrott in Flugrichtung vorne an, bremst es die Objekte ab.

• 11.01.24
• 09:17
• Artikel
• +1

@Dr.Ne0Gen3tic: https://patents.google.com/patent/US11768660B2/en ich denke, dass es um dieses Patent geht:

Das Patent deckt Prozessoren ab die hauptsächlich "low precision but high dynamic range" Arithmetic umsetzen (liest sich für mich nach Google bfloat16). Googles TPU setzen oder setzten vermutlich auf bfloat16 und fallen damit vermutlich unter das Patent. Aber die Ideen klingt jetzt net besonders stützenswert? Die Idee von "low precision but high dynamic range" klingt schützenswerter, aber is auch ne logische Konsequenz, wenn man mal bissi mit KI rumgespielt hat.

• 24.07.23
• 14:18
• Artikel
• +2

@>>Daniel: Die Größe der Software wird mit reingerechnet. Es handelt sich in der Regel also um selbstextrahierende Archive oder aus einer Kombination X Bytes Software + Y Bytes Archiv.