1. Foren
  2. Kommentare
  3. Handy
  4. Alle Kommentare zum Artikel
  5. › Prozessoren: Samsung will auch…
  6. Thema

Meine Fresse...

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


  1. Re: Meine Fresse...

    Autor: hobel 12.09.13 - 13:21

    und in der Firma gibt es keinen der mal ausprobiert haette ob die Anwendung evtl schneller wird, weil es im 64bit Modus doppelt so viele Register gibt?
    Und ich weiss nicht um welche Plattform es geht, aber unter Linux ist die Calling Convention anders, und die ersten Parameter werden in Registern statt auf dem Stack uebergeben, was den Aufruf von Funktionen mit wenigen Paramtern schneller macht.

  2. Re: Meine Fresse...

    Autor: Der schwarze Ritter 12.09.13 - 14:05

    elgooG schrieb:
    > Du solltest echt mal an deiner Ausdrucksweise arbeiten. Redet ihr so mit
    > Kunden?
    >
    > Zum eigentlichen Thema: Klar bei vielen Berechnungen bzw. hohem
    > Speicherverbrauch bringen die breiten Register schon mal unglaublich viel
    > Boost, aber die Codeoptimierung muss eben auch mitspielen, genauso wie der
    > Nutzen bzw. die Notwendigkeit. Man kann einem Endverbraucher nun mal nicht
    > vorwerfen, dass er nicht weiß was es mit 64bit auf sich hat.

    Das kommt ganz darauf an, wie der Kunde mit uns redet. In diesem Fall war der Kunde enorm unfreundlich und hat gemeint, er müsse Bullshit-Bingo spielen. Sprich: Keine Ahnung, was er redet, aber hauptsache, alle möglichen Begriffe mal verwendet. Wo passt dir da meine Ausdrucksweise nicht? Es gibt Kunden, die bei uns mal freundlich angeklopft haben, denen wir das auch freundlich und ausführlich erklärt haben, warum wir das nicht machen. Andere hingegen kommen erst mal in der Einleitung mit "Dieser alte Scheiss hier ist doch... <hier weiteres Geblubber denken>". Da wird der Ton halt unsererseits auch mal etwas ruppiger, aber noch lange nicht unverschämt.

    Oh, vielleicht hätte ich auch noch erwähnen sollen, dass etwa 80-90% unserer Kunden noch XP im Einsatz haben. Weitere Fragen? ;)

  3. Re: Meine Fresse...

    Autor: George99 12.09.13 - 14:24

    thomil schrieb:
    --------------------------------------------------------------------------------
    > Ich als Linux user bin es gewohnt alle meine Programme als 64-Bit Versionen
    > zu haben.

    *hust* skype *hust*

  4. Re: Meine Fresse...

    Autor: /mecki78 12.09.13 - 16:09

    Im Großen und Ganzen gebe ich dir durchaus Recht. Programme mit aller Gewalt und um jeden Preis 64 Bit zu machen, nur weil man es kann, macht nicht automatisch für alle Programme Sinn. Aber deine Aussage, dass sich doch überhaupt nichts dadurch ändert, nur weil ich mein Programm jetzt 64 Bit baue, ist leider in mehrfacher Hinsicht falsch.

    Zum einen gilt auf allen x86 Plattformen: 64 Bit Programme laufen auf der CPU im x86-64 Modus und dieser Modus führt nicht nur dazu, dass Register 64 Bit breit sind, und somit 64 Bit Rechen- und Logikoperationen deutlich schneller durchführbar sind, es führt auch dazu, dass mehr Register vorhanden sind, nämlich 12 generische Register, statt nur 4. Letzteres ermöglicht den Compiler mehr Daten in Registern zu halten (statt in den Speicher, sprich auf dem Stack, auszulagern - Register Spilling) und das wiederum ermöglicht teilweise viel schnelleren und effizienteren Maschinencode. D.h. eine App die viel mit 64 Bit Integern arbeitet oder die komplexere Funktionen besitzt, die von mehr CPU Registern deutlich profitieren können, bekommt alleine durch das Umlegen dieses einen Schalters einen deutlich messbaren Geschwindigkeitsschub.

    Soweit gilt diese Aussage für alle Systeme, ob jetzt OS X, Linux oder Windows, das ist egal. Besonders aber bezogen auf OS X (und ggf. demnächst auch iOS) gibt es hier aber noch weitere Besonderheiten:

    Obj-C wird anders als C++ nicht hauptsächlich in relativ statischen Maschinencode übersetzt, der so ziemlich für sich alleine funktioniert; sofern man keine dynamische Funktionalität in C++ verwendet. Obj-C ist eine extrem dynamische Sprache, die vieles erst zur Laufzeit macht und daher braucht sie für einige Dinge ein "Runtime" (zu deutsch: Eine Laufzeitumgebung). Eine 32 Bit App nutzt die 32 Variante dieser Runtime und eine 64 Bit die 64 Bit Variante. Nicht weiter verwunderlich soweit. Die 64 Bit Obj-C Runtime von Apple ist aber um Welten besser als die 32 Bit Version. Sie ist viel neuer, viel optimierter, viel schneller und kann über diverse Tricks sogar auch noch Speicher einsparen.

    Beispiel: Tagged Pointers
    Ähnlich wie in Java sind in Obj-C Integer Zahlen "primitive Typen", also keine Objekte. Oft braucht man diese Zahlen aber als Objekte. Hierfür gibt es NSNumber, ein Objekt das jeden primitiven numerischen Wert repräsentieren kann. In der 32 Bit Version der Runtime sind NSNumber Objekte immer echte Objekte, d.h. es muss ein Objekt erzeugt werden (alloc/init), dieses Objekt muss den Speichermanagement Pattern von Obj-C folgen (retain/release) und wird dann irgendwann mal wieder zerstört (dealloc). Den numerischen Wert aus diesem Objekt zu holen geht nur über einen echten Methodenaufruf.

    In der 64 Bit Version der Runtime gibt es aber Tagged Pointers. Wenn der numerische Wert einer NSNumber sich direkt im Pointer speichern lässt, dann nutzt Apple einen Tagged Pointer und speichert den numerischen Wert direkt im Pointer. D.h. hier wird in Wahrheit gar kein Objekt erzeugt (kein alloc, kein init), für so einen Pointer muss auch kein Speichermanagement erfolgen (retain/release auf einen Tagged Pointer sind NOP Operationen) und folglich muss so ein Pointer auch nie zerstört werden (kein dealloc). Auch das umwandeln eines solchen Pointers zurück in einen numerischen Wert erfolgt über einen "unechten Methodenaufruf", er sieht zwar genauso aus, aber in Wahrheit erfolgt gar kein echter Methodenaufruf. Ein Tagged Pointer braucht also viel weniger Speicher als ein echtes Objekt und die Runtime kann viele Operationen mit ihm deutlich schneller ausführen. Das schöne ist aber, dass du als Entwickler gar nichts davon merkst, denn ein Tagged Pointer verhält sich immer und überall genau so, als ob er ein echtes Objekt wäre.

    Tagged Pointers werden nicht nur bei NSNumber, sondern z.B. auch bei NSDate benutzt AFAIK (ggf. auch noch bei anderen Objekten). Das ist jetzt auch nur ein Beispiel, tatsächlich gibt es noch viel, viel mehr solche "Tricks" um den Code schneller zu machen in der 64 Bit Runtime.

    Diese ganzen Vorteile erkauft man sich allerdings durch einen Nachteil: Da Pointer jetzt 64 Bit sind (8 Byte), statt 32 Bit (4 Byte) steigt der Speicherverbrauch von Apps, besonders dann, wenn die Apps eben sehr viele Pointer verwenden (und Objekt Referenzen sind auch Pointer, es sind eben nur Pointer die auf Objekte zeigen).

    Nachwort:
    Und bevor jetzt wieder irgendwelche Linux Fanatiker aus der Ecke springen: Ja, in Linux gibt es seit einiger Zeit einen "dritten" Modus. Es gibt den echten 32 Bit Modus (von den habe ich hier gesprochen), den echten 64 Bit Modus (von dem habe ich hier auch gesprochen) und den Hybrid 32-64 Bit Modus (von dem habe ich hier nicht gesprochen). Der Hybrid Modus funktioniert so, dass die CPU zwar im 64 Bit Modus arbeitet (also 64 Bit breite Register und mehr davon), aber Pointer dennoch nur 32 Bit sind (der virtuelle Adressraum ist trotzdem auf 4 GB beschränkt). Das ist ein ziemlicher Hack IMHO, der es Code ermöglichen soll die Vorteile von 64 Bit CPUs zu nutzen (zumindest die meisten, bis auf den größeren Adressraum natürlich), ohne die Nachteile in Kauf nehmen zu müssen.

    AFAIK ist dieser Modus etwas, das derzeit nur für Linux existiert (vielleicht auch nie für etwas anderes existieren wird) und er ist nach wie vor mehr ein Experiment, denn ich kenne keine große Distributionen, die z.B. komplett auf diesen Modus setzen würde oder diesen Modus auch nur ab Werk unterstützt. Denn dieser Modus hat eine andere ABI (das ist der Standard der beschreibt, wie z.B. ein Funktionsaufruf aufgebaut ist, also z.B. wie und wo werden Parameter/Rückgabewerte übergeben, wie ist der Stack aufgebaut, etc.) und das bedeutet, ein Programm kann nur Libraries benutzen, die auch speziell für diesen Modus gebaut wurden. Ich finde es cool das man so was überhaupt machen kann und ich finde es auch cool das es Leute gibt, die so etwas machen wollen und entsprechend auch Support dafür in Linux einbauen.

    Allerdings ist das mehr ein Spezialanwendungsfall, der für Geräte gedacht ist, die eine 64 Bit CPU haben und diese auch wirklich ausnutzen wollen (oder müssen, weil sie aufwendige 64 Bit Berechnungen durchführen sollen), allerdings nur über sehr wenig oder nur sehr langsames RAM verfügen (könnte also z.B. im embedded Bereich interessant sein für embedded Geräte mit 64 Bit CPU). Im Desktop oder Serverbereich sehe ich nicht wirklich dass dieser Modus eine sehr große Verbreitung finden wird (wie gesagt, abgesehen von einigen Spezialanwendungsfällen vielleicht).

    /Mecki

  5. Re: Meine Fresse...

    Autor: kendon 12.09.13 - 16:27

    und hast niemanden ausser ihm geantwortet.

  6. Re: Meine Fresse...

    Autor: Quantium40 14.09.13 - 02:28

    thomil schrieb:
    --------------------------------------------------------------------------------
    > Ich als Linux user bin es gewohnt alle meine Programme als 64-Bit Versionen
    > zu haben.
    > Das erspart mir, dass ich zusätzlich zu den 64-Bit libraries auch
    > noch die 32-Bit Versionen im RAM haben muss.
    Da 64-Bit-Code weniger dicht ist, geht die Ersparnis bei den 32-Bit-Libraries eh für den erhöhten Platzbedarf der 64-Bit-Libraries drauf.
    Da aber bei dir RAM extrem knapp zu sein scheint, solltest du eher überlegen, auf ein 32-Bit-System zu wechseln. Die MMU im x86-Bereich unterstützen in der Regel auch für 32-Bit-Programme Speicher jenseits der 4GB-Grenze, solange sich der einzelne Prozess mit max. 4GB begnügt.
    Schneller werden 64-Bit-Programme in der Regel nicht durch die Nutzung der breiteren allgemeinen Register. Gerade bei aktuellen CPUs kommt ein Leistungsboost eher aus SSE, AVX oder ähnlichen SIMD-Features.

  7. Re: Meine Fresse...

    Autor: Arkarit 16.09.13 - 08:14

    thomil schrieb:
    --------------------------------------------------------------------------------
    > Ich als Linux user bin es gewohnt alle meine Programme als 64-Bit Versionen
    > zu haben. Das erspart mir, dass ich zusätzlich zu den 64-Bit libraries auch
    > noch die 32-Bit Versionen im RAM haben muss.
    >
    > Das könnte man unter Windows genauso haben, und sich dadurch einiges an RAM
    > sparen. Leider wird man wegen solch ewig-gestrigen wie euch auch in 10
    > Jahren unter Windows noch alle Libraries doppelt im RAM haben...

    Oh Schreck! Schon heute leide ich extrem unter der Tatsache, daß ich nur 15120 MB RAM frei habe, wo es doch 15230 sein könnten! Wie soll das dann erst in 10 Jahren werden?

  8. Re: Meine Fresse...

    Autor: kendon 16.09.13 - 10:03

    da fällt dein freier speicher unter die magische grenze von 15000 mb und dein pc wird unbenutzbar. zumindest unter windows, unter linux hat man eh keinen freien speicher. braucht ihn aber auch nicht, denn freier speicher ist verschenkter speicher...

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. Radeberger Gruppe KG, Frankfurt am Main
  2. Landratsamt Starnberg, Starnberg
  3. DAAD Deutscher Akademischer Austauschdienst e.V., Bonn
  4. Telio Management GmbH, Hamburg

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. 12,99€
  2. 16,49€


Haben wir etwas übersehen?

E-Mail an news@golem.de


  1. Microsoft: Die 85-Zoll-Version des Surface Hub kommt
    Microsoft
    Die 85-Zoll-Version des Surface Hub kommt

    Das große Surface Hub 2S wird ebenfalls auf Windows 10 Pro aufrüstbar sein. Außerdem gibt es einen Patch auch für die erste Generation.

  2. Cisco und Apple: Chinas Führung hat eigene schwarze Liste gegen US-Konzerne
    Cisco und Apple
    Chinas Führung hat eigene schwarze Liste gegen US-Konzerne

    Cisco und Apple dürften in China ausgeschlossen werden, wenn China die Maßnahmen von Trump kontert. Doch wann das passiert ist umstritten.

  3. Openreach: Alter Fernseher stört ADSL für ein ganzes Dorf
    Openreach
    Alter Fernseher stört ADSL für ein ganzes Dorf

    Anderthalb Jahre brauchen die Openreach-Techniker, um eine Störung in der ADSL-Versorgung zu finden. Eine ganze Kabelstrecke wurde erneuert, doch ohne Ergebnis.


  1. 20:00

  2. 18:56

  3. 17:50

  4. 17:40

  5. 17:30

  6. 17:30

  7. 17:15

  8. 17:00