Nutzt .NET!

Es gibt 77 Antworten in diesem Thema. Der letzte Beitrag () ist von Samus Aran.

    SeriTools schrieb:

    Beleg? Quelle?


    Eigens gestern und eben ausprobiert. Ein Benutzersteuerelement, welches Last erzeugt. Mehr davon eingebaut und es waren laut Taskmanager alle 4 Kerne beschäftigt. Allerdings nicht zu 100 % ausgelastet. Ich nutze einen Intel i5-2400 auf einem P8H67 Mainboard und Win7 64Bit. Wer da jetzt die Last verteilt ist mir leider nicht wirklich klar.
    Bilder
    • Zwischenablage01.jpg

      228,28 kB, 1.283×799, 124 mal angesehen
    Gruß
    Peterfido

    Keine Unterstützung per PN!
    schau dir mal in der Lasche "Prozesse" die Spalte "Threads" an während deine Anwendung läuft.
    Sollten nach deine "Last-erzeugung" mehrere Threads dazukommen kannst du von Multithreading reden.
    Sonst nicht.
    Was sollte eine CPU denn sonst machen wenn nicht mehr arbeiten wenn sie belastet wird?
    13 Threads sind erstens nicht unbedingt positiv bei einem einfachen Musikplayer
    und 2tens wirst du diese dann wohl nicht selbst erstellt haben, sondern mit irgendwelchen externen Funktionen/Dlls...
    Ich wollte auch mal ne total überflüssige Signatur:
    ---Leer---
    Scheint, als ob Dir das Ergebnis einfach nicht gefällt. Läuft keine MP3 sind es noch 11 Threads. Wobei ich hauptsächlich APIs nutze. Dass diese dann auf neueren Windowsversionen auch moderner funktionieren spricht dann wieder für VB6. Die drei integrierten Player sind ein Benutzersteuerelement, welches die Bass.dll nutzt. An dem Projekt arbeite ich seit einigen Jahren. Im Hintergrund werden die Längen der Stücke ermittelt, um eine Gesamtdauer anzeigen zu können. Dies hat bei meinem Lösungsweg die Folge, dass MP3s mit variabler Bitrate komplett eingelesen werden. Bei der Version ohne die Bass.dll (mit MCI) laufen 5 Threads während der Aktualisierung des Inhaltsverzeichnisses. Allerdings ist diese von 2006.

    Dann noch ein OLE-Server, welcher nur gebraucht wird, wenn aus dem Explorer eine MP3 doppelt geklickt wird. Dies startet eine weitere Instanz, welche erkennt, dass bereits eine läuft und schickt dann den Dateinamen an diese. Anschließend wird es gleich wieder beendet. Möglich, dass es einfacher geht, mir ist aber kein anderer Weg eingefallen und da es immer noch so läuft, habe ich auch nicht weiter gesucht.

    Der Grund für dieses Topic war aber nicht, ob VB6 mehr Threads kann, sondern dass davon abgeraten wird. Das mit den mehreren Threads ist ja nun belegt.

    Die genutzten dll´s :
    Bilder
    • Zwischenablage01.jpg

      123,32 kB, 1.289×939, 103 mal angesehen
    Gruß
    Peterfido

    Keine Unterstützung per PN!

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „peterfido“ ()

    Der Grund für dieses Topic war aber nicht, ob VB6 mehr Threads kann, sondern dass davon abgeraten wird. Das mit den mehreren Threads ist ja nun belegt.

    Dass es das kann, war von Anfang an klar(da es jede Sprache so gesehen kann, welche WinAPI unterstützt - also lasst es uns in Brainfuck programmieren -.-), aber es kann nicht, ohne WinAPI, oder externe dlls...
    Und du hast ja anscheinend einige Dlls benutzt...
    Ich wollte auch mal ne total überflüssige Signatur:
    ---Leer---
    Ja sicher. Die meisten davon bringt VB6 (bzw. die neueren Windowsse) mit. Die von mir markierten nicht. Wobei ich mir bei der sccrun nicht sicher bin, ob die nicht eh jedes Windows dabei hat. Da ist quasi das gesamte "Framework" in den Dateien. Aber auch das .NET Framework spricht die APIs an. Man braucht sie halt nicht mehr extra umständlich definieren. So gesehen ist .NET eine höhere Sprache. VB war allerdings immer eine höhere Sprache als C(++) und diese höher als ASM. Je höher eine Sprache, desto einfacher ist sie normal zu gebrauchen aber schwerer im internen zu beeinflussen. Die KidsPL demnach wohl höher als .NET.

    Die höchste Sprache wäre wohl in etwa so:

    VB.NET-Quellcode

    1. dim a as Supermegageiler3dShooter
    2. sub main
    3. call a
    4. end sub
    Gruß
    Peterfido

    Keine Unterstützung per PN!

    jvbsl schrieb:

    13 Threads sind erstens nicht unbedingt positiv bei einem einfachen Musikplayer

    Wobei das "echte" (native) Threads sind, die kann man nicht direkt mit "managed" threads vergleichen. Da läuft halt viel im "Hintergrund" auf das man keinen Einfluss hat. Ich hab zb letztens mal 4 Tasks gestartet und die Threadzahl ging von 15 auf 25 rauf.
    Außerdem sagt die ANZAHL der Threads erstmal nix über Parallelität. zb kann ich in Thread A Thread B starten und dann ThreadB.Join machen. Dann habe ich zwar ZWEI threads, aber nur einer arbeitet bzw kann reagieren.

    @Alex:
    VB war allerdings immer eine höhere Sprache als C(++)

    Das ist völlig korrekt. Dass heißt, wer sich zurückhalten muss ist nicht PF ... Vlt solltest du dich mal informieren, was "höher" bedeutet? Es gibt zwar streng genommen keine "Reihenfolge" der hPS aber i.A. geht man davon aus, dass "je weiter weg" von der "Maschine", desto "höher" (abstrakter). Und maschinenferne wird man C/C++ wohl kaum vorwerfen können ...
    btw, @PeterFido:
    Ich schrieb hier:
    [VB.NET] DataGridView Ping IP/Host aus DB

    jenes:

    VB.NET-Quellcode

    1. Private Async Sub TestAll(ByVal l As List(Of Net.IPAddress))
    2. Dim lt As New List(Of Task(Of Net.NetworkInformation.PingReply))
    3. For Each u As Net.IPAddress In l
    4. lt.Add((New Net.NetworkInformation.Ping).SendTaskAsync(u))
    5. Next
    6. While lt.Count > 0
    7. Dim t = Await TaskEx.WhenAny(lt)
    8. Debug.Print(t.Result.RoundtripTime.ToString)
    9. lt.Remove(t)
    10. End While
    11. End Sub


    Zeig doch mal, wie du das mit VB6 realisieren würdest.