2024-02-11, 05:24
  #169
Medlem
BeneathTheSurfaces avatar
Citat:
Ursprungligen postat av Battreanmig.
Nått måste dem förstå. Som att när man skriver Google i webbläsaren så kommer söksajten Google som val.

Är inte det att förstå?

Datorer förstår enbart maskinkod, vad som händer när du skriver ”google” i webläsaren är helt ett resultat av vad de som utvecklade chrome bestämde skulle hända.
en dator gör exakt vad den blir tillsagd att göra.
Citera
2024-02-17, 02:10
  #170
Medlem
Här finns en mycket intressant artikel i CodeProject - ett diskussionsforum kopplat till GitHub.
Att C++ ger snabbare kod än C:

https://www.codeproject.com/Tips/537...-C-Equivalents

Citat:
Two C++ Features Win Over C Equivalents

Shao Voon Wong

Two C++ features win over C equivalents in performance

The tip explores the superior performance of C++ over C in sorting and summing operations, showcasing benchmarks that reveal significant speed advantages of C++ over C.
This short write-up showcases two tricks C++ developers use to gain performance over C. As such, it is not eligible to participate in the CodeProject monthly article competition.

Introduction

When it comes to performance, C is king, but there are two areas in which C++ is supreme over C: sorting and summing. When the benchmark results were revealed, the C programmers were baffled and intrigued, and finally, they were won over to the C++ side. In this tip, we examine the reason they are faster and see if it is still the case today by benchmarking.

Standard sorteringsalgoritmen Quicksort är numera ersatt av en annan hybridsorteringsalgoritm IntroSort i C++ stdlib, som undviker för djupa rekursioner vilket kan inträffa med Quicksort.

Det är bara två exempel men författaren Shao Voon Wong
motiverar väldigt bra för att testen är jämförbara.
Och artikeln är mycket välskriven i all sin enkelhet.

Anmärkningsvärt är att Visual Studio C++ ger så pass mycket bättre prestanda på koden än gcc + libs gör.
Mycket intressanta prestandasiffror faktiskt.

Det framgår inte i artikeln varför men gcc har en mycket tung ryggsäck av att den måste hålla sig bakåtkompatibelt med de flesta libs och headers, sedan typ hedenhös.

I CodeProject togs det upp för några veckor sedan att grafikkortstillverkarna inte har kunnat enas om någon ny standard för grafiklib.

Och att Apple kommer att dumpa OpenGL för sin egen "Metal":
https://venturebeat.com/games/apple-...aten-to-leave/

Istället så propagerar Apple för sin egen "grafikmotor" "Metal".

Här vet vi inte vad som kommer att hända.

Apple verkar ha skjutit sig själva i foten med att dumpa OpenGL,
och verkar inte erbjuda någon förklaring till detta ?
Elaka rykten säger att Apple inte fått tag i tillräckligt med folk som kan OpenGL.

Skumt är dock att Apple inte har kommit ut med massor av exempelkod på sin
grafikmotor Metal ?

Risken finns nu att spelutvecklarna inte vet vilken grafikstandard som kommer att gälla
framöver och att det blir för dyrt att skriva om spelen från scratch.

Här är en artikel som jämför OpenGL med tex Vulkan:
https://thatonegamedev.com/cpp/opengl-vs-vulkan/
__________________
Senast redigerad av DrSvenne 2024-02-17 kl. 02:30.
Citera
2024-02-17, 09:53
  #171
Medlem
BeneathTheSurfaces avatar
Citat:
Ursprungligen postat av DrSvenne
Och att Apple kommer att dumpa OpenGL för sin egen "Metal":
https://venturebeat.com/games/apple-...aten-to-leave/

Istället så propagerar Apple för sin egen "grafikmotor" "Metal".

Här vet vi inte vad som kommer att hända.

Apple verkar ha skjutit sig själva i foten med att dumpa OpenGL,
och verkar inte erbjuda någon förklaring till detta ?
Elaka rykten säger att Apple inte fått tag i tillräckligt med folk som kan OpenGL.

Skumt är dock att Apple inte har kommit ut med massor av exempelkod på sin
grafikmotor Metal ?

Risken finns nu att spelutvecklarna inte vet vilken grafikstandard som kommer att gälla
framöver och att det blir för dyrt att skriva om spelen från scratch.

Vad yrar du om? Apple bytte till Metal för drygt 5 år sedan, OpenGL finns fortfarande men vare sig uppdateras eller får något ramverksstöd i någon utsträckning och spelindustrin har gått från OpenGL sedan massvis med år tillbaka.

Det finns massvis med Metal exempel kod på developer.apple.com
Citera
2024-04-12, 23:26
  #172
Medlem
MKGs avatar
Citat:
Ursprungligen postat av JohanZzZ
Jag menade att det finns skillnad på high level Assembly som t. ex.
Kod:
my_var:
dd 0
där till exempel NASM skapar en variabel med värdet noll istället för en annan variant av Assembly där Assembly har en 1:1 mapping till maskinkod då, åtminstone i ett ELF-objekt, my_var placeras i en symbol table. Jag tror att den också finns med i en relocation table till den färdiga exekveringsbara filen då värdet hamnar direkt i data section, och koden kan se ut ungefär såhär om värdet istället är ett:
Kod:
movl $0x1,0x2ec1(%rip) 
(AT&T assembly syntax.)

Alltså: lägg värdet ett i början av data section.

I de flesta fall så genererar en kompilator minst lika snabb kod åt dig som när du skriver ren Assembly-kod, Och det gäller både för C++ och C. I vissa fall där du skriver mer skräddarsydd kod så kan din kod bli snabbare.

En x86:a ja. Jag sitter ii ett projekt där vi bygger en kompilator för PowerPC och där har man inte lika feta instruktioner som på en x86:a, eftersom PPC-n är en RISC-processor och x86 en CISC-processor.
PPC har betydligt fler och betydligt generellare register än en x86. Det finns inget dedicerat register för att peka på stackens top t.ex. vilket det gör på en X86 (SPX), oftast använder man det generella registret 1 (R1). Glöm instruktioner som kan dumpa alla register på stacken med en end instruktion (x86), på en PPC för man plocke register för register, och de är många...

Det gör att det inte är så självklart vilket språk som är "snabbast" på en viss processorplattform.. och det gör att assemblerspråken ser ganska olika ut. Joxr lite med gamla SPARC också (RISC)...
Det är ju betydligt enklare att sätta upp en C-kompiltor för en CISC-processor som x86, den känns ju mer "byggd" för att kunna implementera kompilatorer på.
Citera
2024-04-16, 15:06
  #173
Medlem
Citat:
Ursprungligen postat av MKG
En x86:a ja. Jag sitter ii ett projekt där vi bygger en kompilator för PowerPC och där har man inte lika feta instruktioner som på en x86:a, eftersom PPC-n är en RISC-processor och x86 en CISC-processor.
PPC har betydligt fler och betydligt generellare register än en x86. Det finns inget dedicerat register för att peka på stackens top t.ex. vilket det gör på en X86 (SPX), oftast använder man det generella registret 1 (R1). Glöm instruktioner som kan dumpa alla register på stacken med en end instruktion (x86), på en PPC för man plocke register för register, och de är många...

Det gör att det inte är så självklart vilket språk som är "snabbast" på en viss processorplattform.. och det gör att assemblerspråken ser ganska olika ut. Joxr lite med gamla SPARC också (RISC)...
Det är ju betydligt enklare att sätta upp en C-kompiltor för en CISC-processor som x86, den känns ju mer "byggd" för att kunna implementera kompilatorer på.

Ja, så är det nog. C har också sina begränsningar.
Citera

Skapa ett konto eller logga in för att kommentera

Du måste vara medlem för att kunna kommentera

Skapa ett konto

Det är enkelt att registrera ett nytt konto

Bli medlem

Logga in

Har du redan ett konto? Logga in här

Logga in