mboost-dp1
NASA
#6
Fordi de ikke har råd til en Core i5... Roveren har jo kun en 200 MHz PowerPC 750 CPU... Så hvis ikke al performance skal gå til hele det overhead et Managed sprog har. Så er man nødt til at køre C eller C++
Dernæst er C og C++ nogle af de eneste 'realtime' sprog
Fordi de ikke har råd til en Core i5... Roveren har jo kun en 200 MHz PowerPC 750 CPU... Så hvis ikke al performance skal gå til hele det overhead et Managed sprog har. Så er man nødt til at køre C eller C++
Dernæst er C og C++ nogle af de eneste 'realtime' sprog
Var der ikke planer om at opdatere koden efter landing eller husker jeg forkert?
#6 Bare af interesse: Hvilket sprog vil du foreslå?
#6 Bare af interesse: Hvilket sprog vil du foreslå?
Det har tidligere været oppe hvorfor NASA bruger en ældre CPU.
Se disse links:
http://newz.dk/curiosity-anvender-powerpc-cpu-fra-...
http://en.wikipedia.org/wiki/Curiosity_rover
Se disse links:
http://newz.dk/curiosity-anvender-powerpc-cpu-fra-...
http://en.wikipedia.org/wiki/Curiosity_rover
Mnc (11) skrev:Jeg tror nu nok at NASA har råd til en i5'er, spørgsmålet er nok nærmere om en i5'er er bygget til at kunne tage de tæv som en tur til og på Mars vil give den. :)
Impact, radiation, etc.
Nu er det ikke et økonomisk spørgsmål, men snarere i forhold til f.eks strømforbrug samt overhead mm i software arkitekturen som #7 også er inde på...
Montago (7) skrev:Fordi de ikke har råd til en Core i5...
og @13
Tror mere det handler om at det hardware skal være bygget specielt til at kunne overleve en tur i rummet, der er jo enorme mængder af kosmisk stråling, solstorme og lignende som kan give problemer for standard hardware..
Desuden begyndte de byggeriet af Curiousity for 7 år siden (mener jeg det var), og tror ikke bare de lige uden problemer kan lave store ændringer på hardware fronten i det sidste minut.
cryo (6) skrev:Faktisk lidt underligt at man vælger et så typesvagt og "error prone" sprog som C til missionskritiske systemer. Man burde bruge noget hvor man har en chance for at ræsonere om korrekthed.
Jeg undrede mig også over det valg.
Montago (7) skrev:Roveren har jo kun en 200 MHz PowerPC 750 CPU... Så hvis ikke al performance skal gå til hele det overhead et Managed sprog har. Så er man nødt til at køre C eller C++
Det argument holder ikke.
1) Managed sprog har ikke nævneværdigt ekstra CPU forbrug (de har dog et forholdsvis stort opstarts memory forbrug).
2) Der er masser af andre unmanaged sprog end C og C++.
Montago (7) skrev:Dernæst er C og C++ nogle af de eneste 'realtime' sprog
De kunne sagtens have et krav om rimeligt gode realtime egenskaber.
Men også her er der alternativer.
1000tusind (8) skrev:Bare af interesse: Hvilket sprog vil du foreslå?
Ada virker ret oplagt.
Stærk type sikkerhed.
God support for real time.
Lang tradition for brug i "ting".
Til sådan et projekt bruger man nok udviklere, der har evner nok til at lære et nyt sprog.lorenzen (16) skrev:det er dog også et uddøende sprog - så det kan være de har vurderet at det var risikoen værd at bruge c da udbudet af arbejdskraft ville være større.
Så man bør sammenligne hvad kvalitet af kode man kan forvente fra hhv. udviklere med erfaring fra andre sprog, som bliver sat til at udvikle Ada kode og på den anden side kode skrevet i C++ af en udvikler med erfaring i sproget.
Et sprog som giver mulighed for begynderfejl, som kan få katastrofale følger på et senere tidspunkt ville være et dårligt valg. Sådan et sprog ville også være et dårligt valg, hvis man kan finde erfarne udviklere. For selv erfarne udviklere kan begå fejl, og det er ikke altid, at man kan gennemskue, hvor meget erfaring en potentiel medarbejder reelt har.
Jeg er selv mere end én gang blevet ansat til at udvikle i sprog hvor jeg havde meget lidt eller slet ingen erfaring. Og det er vel at mærke situationer, hvor arbejdsgiveren har været fuldstændigt klar over, hvor lidt erfaring jeg havde med det pågældende sprog.
arne_v (18) skrev:#Ada alternativ
Erlang kunne også være en mulighed.
Det er svært at skrive et styresystem i Erlang, der er man nødt til at bruge sprog som C/C++ eller assambler.
Man kunne godt skrive applikationerne i Erlang men lige så snart du skal snakke med hardware skal du over i C/C++.
#20
Hardware interface kræver native kode.
P.g.a. *nix og Windows bliver C/ C++ ofte opfattet som sproget for OS.
C er da også ret velegnet til formålet, da sproget er designet til formålet.
Men der er masser af eksempler på brug af andre sprog:
Multics - PL/I
MPE - Pascal
Bliss - TOPS, RSX, VMS etc.
Hardware interface kræver native kode.
P.g.a. *nix og Windows bliver C/ C++ ofte opfattet som sproget for OS.
C er da også ret velegnet til formålet, da sproget er designet til formålet.
Men der er masser af eksempler på brug af andre sprog:
Multics - PL/I
MPE - Pascal
Bliss - TOPS, RSX, VMS etc.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund