News Windows .NET Server 2003 doppelt so schnell wie Vorgänger?

Tommy

Chef-Optimist

Teammitglied

Registriert

März 2001

Beiträge

8.193

• 26. November 2002

• #1

Windows .NET Server 2003, das kommende Server-Betriebssystem von Microsoft, wird eine deutlich höhere Performance bieten als seine Vorgänger, das ergaben laut Microsoft interne Tests. Die meisten Aufgaben würden mindestens doppelt so schnell verarbeitet wie bei Windows 2000 Server.

Zur News: Windows .NET Server 2003 doppelt so schnell wie Vorgänger?

 

A

Anonymous

Gast

• 26. November 2002

• #2

Hmm ist des also der Nachfolger von Win2000? wird das System auch die neun 64Bit Prozessoren von AMD unterstuetzen und wird es auch bei Spielen schneller sein als die anderen OS? Und hoffentlich nicht ne Ähnlickeit mit WinXP haben.

 

A

Anonymous

Gast

• 26. November 2002

• #3

das ist ein Serverbetriebssystem und wohl kaum für den privaten Anwender gedacht und es wird mit Sicherheit den Hammer unterstützen

 

A

Anonymous

Gast

• 26. November 2002

• #4

! Linux bzw. Unix Server rulen !

 

A

Anonymous

Gast

• 26. November 2002

• #5

Also für Spiele ist das OS sicher nicht optimiert!
Es geht hier um Server Performance - das ist nicht vergleichbar, mit dem, was du so damit machen würdest Seddo.

 

A

Anonymous

Gast

• 26. November 2002

• #6

wieso nicht?
das os führt im serverbetrieb auch nur programmcode aus
wenn das z.b. durch besseres speichermanagesment schneller geht?

 

A

Anonymous

Gast

• 26. November 2002

• #7

@Seddo

Ich glaube nicht, daß man das als Normal-Anwender braucht. Für "uns" gibt es dann WinXP 64-bit. Außerdem wird Windows.NET recht teuer sein

 

A

Anonymous

Gast

• 26. November 2002

• #8

WinXP mit Win.NET zu vergleichen ist wie Äpfel mit Birnen zu vergleichen. Ich glaube nicht, dass die Performance für zB Spiele besser ist; es könnte sogar sein, dass sie schlechter ist wenn man der News folgt: Das Scheduling wurde verbessert und es ist die Rede von Systemen >=64 CPUs. Daraus schließe ich, dass dann mindestens über 100 Threads parallel laufen und das Scheduling dafür optimiert wurde. Bei Spielen bekommen die Hersteller (meistens) nicht einmal 2 Threads zusammen und somit wird das nicht optimal laufen.
Auch der Hardwaresupport für aktuelle "Spiele-Grafikkarten" wird sich sicherlich in Grenzen halten

 

A

Anonymous

Gast

• 26. November 2002

• #9

@Peppo:
Aber auch nur da und wer weiß, wie lange noch.

Tot dem Unix !

 

A

Anonymous

Gast

• 26. November 2002

• #10

@Blutsmurf:
nu sindma da nu krichta uns nimma wech! ausserdem, wer rult hier? m$ im kommerz, unix in der technologie. und aufm desktop demnächst auch. windoof brauchste nurnoch zum spielen. habe fertich.
may the flamewar begin..... ;D

 

A

Anonymous

Gast

• 26. November 2002

• #11

Ich bekomme unter Windows.NET Server RC1 meine SB Audigy Player nicht installiert. Der Treiber verursacht immer wieder einen BSoD.

 

A

Anonymous

Gast

• 26. November 2002

• #12

@ tuxistoll
Da haste aber recht

 

A

Anonymous

Gast

• 27. November 2002

• #13

Windows .NT Server hat die Version-Nr. 5.2 Windows XP 5.1.
Es sind die gleichen Treiber wie fuer Windows XP.
PS: Die Spiele laufen auf einem WINDOWS .NET Server RC2 schnell als bei WINDOWS XP. :->

 

A

Anonymous

Gast

• 27. November 2002

• #14

Hmm ist des also der Nachfolger von Win2000?

nö, von 2k _SERVER_
-----
wird das System auch die neun 64Bit Prozessoren von AMD unterstuetzen

ist anzunehmen . INTEL ITANIUM wird 100% suported das is sicha
---
und wird es auch bei Spielen schneller sein als die anderen OS?

glaube ich ned (Win9x bleibt meistens performanter hier)
---
Und hoffentlich nicht ne Ähnlickeit mit WinXP haben.

Hats aba
---
auserdem ned alles glauben was M$ da oben schreibt Das mit schnelligkeit sollen erstmal andere auser ms nachweisen
STABILER wohl kaum is ja kein unix-like-kernel

---
Ich bekomme unter Windows.NET Server RC1 meine SB Audigy Player nicht
---
LOL was instalierscht du sepp au ne player soundkarte auf nem server OS überhaupt wohl kein peil ? naja creative hat nie wirklich jute treiber geschrieben zumindest brauchen sie sehr lange um was halbwegs stabiles abzuliefern.

@Jo FYI: die anzahl der threads ist komplet irrelevant. Wenn eine APP sie auf eine CPU-instanz bindet is es eh fuern arsch Auserdem sind threads "quasi" parallel genau wie prozesse auch auf einer CPU.

 

A

Anonymous

Gast

• 27. November 2002

• #15

alles wurscht ;o)

ich vergnüg mich mit der longhorn alpha *g* und nebenbei mit dem Win .NET build 3718 da löppt audigy, tv-karte und alle games..

 

A

Anonymous

Gast

• 27. November 2002

• #16

@blubbr

"LOL was instalierscht du sepp au ne player soundkarte auf nem server OS überhaupt wohl kein peil ?"

Weil sie nunmal in meinem Rechner steckt, du sepp.
Zu deiner letzten Bemerkung:
" Nur der Wissende weis, das er nichts weis."
Denk mal drüber nach. Du Sepp.

MfG

 

A

Anonymous

Gast

• 27. November 2002

• #17

@blubbr:
" Auserdem sind threads "quasi" parallel genau wie prozesse auch auf einer CPU. "

Eben nur quasi-parallel, wenn nur eine CPU-ist (wobei quasi-parallel mit "überhaupt-nicht-parallel" gleichzusetzen ist).
Bei mehreren Prozessoren werden die Threads, falls richtig programmiert und gescheduled parallel ausgeführt.

@Michael:
Die Treiber werden schon meistens funktionieren, aber sie sind nicht für Win.NET optimiert und funktionieren eben nicht immer. Siehe zB SB Player die ja sehr viele Spieler besitzen.

@Tuxistoll: Der Kernel mag stabil sein, aber der "Desktop", also die graphische Oberfläche sicherlich nicht (wird aber im server-Bereich auch nicht gebraucht): Drag&Drop geht nicht. wirklich, der KDE-Konquerer stürzt häufig ab, der Gnome-Galeon ist äußerst langsam und von die Übersetzer machen ihren Job nicht unbedingt sehr gut.

 

A

Anonymous

Gast

• 27. November 2002

• #18

@Jo
SB Live + SB AD Player laufen bei mir sehr gut unter .NET 3716

Gruss
Michael

 

A

Anonymous

Gast

• 27. November 2002

• #19

@Jo wenn du mit "richtig programiert" die nicht-bindung-an-eine-cpu meinst dann ACK! Threads kanst du nicht "falsch" programieren. Das sind meistens konstrukte (wie Klassen zb) des jewiligen frameworks/P-Sprache. Prozesse sind wiederum Konstrukte eines BS.
(wobei quasi-parallel mit "überhaupt-nicht-parallel" gleichzusetzen ist) => wenns denn so waere meuste man keine Synchroniesierung auf gemeinsamen resourcen vornehmen ( was du sagen willst ist eher das auf einer CPU die threads sequentiell ablaufen in einem bestimmten Zeitpunkt gesehen, da jedoch das context-switching beim scheduler extrem shcnell ist bei heutiger hardware sehen wir menschen das als parallel an OK?)


@Ingmar (aka sepp :-) : dann mach sie weg da Wenn du jetz noch sagst das ein SERVER-OS ubedingt in verbindung mit ner gamer soundkarte betreiben wilst dann ahst du nicht wirjklich ahnung. Den sowas muss nicht mal creative supporten! Deren hauptverkaufziel sind eben homeuser mit consumer-OS'es wie 2k/XP/9x und ned server produkte. (Ich tipp mal das du so gesehn nicht wirklich ein Server-OS bruchst )

" Nur der Wissende weis, das er nichts weis." - also wenn du der wissende bist dann verstehe ich deine Ausfuhrungen vollkommen

 

A

Anonymous

Gast

• 27. November 2002

• #20

@Michael:
"wenn du mit "richtig programiert" die nicht-bindung-an-eine-cpu meinst dann ACK! Threads kanst du nicht "falsch" programieren. "
Doch, es kann zum Beispiel die Last nicht gleichmäßig auf Threads verteilt sein oder sie sind nicht unabhängig genug, sodass die Synchronisation den Vorteil von Threads "vernichtet"


"Das sind meistens konstrukte (wie Klassen zb) des jewiligen frameworks/P-Sprache. Prozesse sind wiederum Konstrukte eines BS. "
Das stimmt i.A. nicht; ob Threads auf Betriebssystemebene oder auf user-level-ebene ablaufen, hängt vom jeweiligen Betriebssystem ab. Dies beeinflusst somit auch die Context-Switch-Zeit, sodass diese nicht unbedingt so schnell sein muss.