#programming #gamedev #cpp #assembly #x86 I made the same game in x86 assembly, C and C++ to see how they compare. 💭 All views are my own 💭 Link to source: github.com/iris-engine-dev/as...
This reminded me of the time a colleague thought he could rewrite his C code in assembly to get more performance, what he learnt at the end was that the C compiler optimisation was much better than his assembly coding skills.
yeah compiler nowadays are really smart though, normally when you write your C code and let the compiler optimizes it aggressively, then you compare to your asm code, it's just no competition
Every time someone finds a cool way to optimize assembly code, they just add that optimization to the compiler. Modern compilers are just effectively 20+ years of knowledge packed into one little box.
Yeah, there are only very rare circumstances in which you could get any speed gain by rewriting something in Assembly. See for example Lua vs LuaJIT, where LuaJIT's interpreter is written in Assembly in order to store some important state in the same registers while the interpreter is running, and to speed up the fetch-decode-execute loop as much as possible. No C compiler can do that kind of thing at the moment.
This is the kind of comment that I find very strange. I think that people just haven't thought through what can be optimized and what can't, but everytime that I _thought_ that I could out perform the compiler, I was correct. I don't feel like I can do any better most of the time, however.
Binary (i.e. machine code) = assembly language, or, to put it another way, assembly language is a 1:1 version of machine code using opcode mnemonics. Crucial note: all opcode mnemonics are known during the CPU's final design stage - writing in 'machine code' = writing using the numeric values of these opcodes. Assembly language is, essentially, writing machine code using the human-readable mnemonic text version of opcodes. No one writes in 'machine code' - it's all assembly, and always has been (on paper in the 'early days', with the machine code translated version along side ready to be loaded). Of course, an embedded system (e.g. space/satellite etc devices) will be pre-loaded with the 'assembled' (i.e. binary) version of a program.
@@ChrisM541”no one writes in machine code” That’s weird, in my FPGA class everyone wrote in machine code. Except me because I wrote an assembler, but an assembler doesn’t always exist. And even my simple assembler generated machine code that didn’t map 1:1 to assembly. You don’t know what you’re talking about.
I’m 59 and wrote my first program in an assembly type language in 1977. We are truly standing on the shoulders of giants. I am an aerospace engineer, but still need to write code to automate engineering tasks. Visual Studio is my environment of choice because it makes my job so simple.
I recently switched from Notepad++ to Visual Studio (not Code). I am surprised how bad it is at basic tasks, like search and replace (it's slow and half the time doesn't replace or skips one replace). It also takes up 700MB in memory when running.
I'm impressed. My mom was an engineering aid working at the Boeing wind tunnel facility. She had the neatest pens for plotting out the results. She claimed she got sent to take Fortran classes because the engineers couldn't be bothered.
I can write something like this in C without ever looking at a line of doc or doing a Google search while I feel everything looks complicated in C++ and I spend a lot of time searching and doubting myself. The fact the author feels a class of library was helpful for this leaves me perplex as well... when all you need is a few structs and arrays.
What makes compiler optimization so great is its not just a single bit of contributed ideas from a single person whose smart in the field of assembly, but its a collection of all the smartest techniques anyone could functionally think of to optimize your code, as a result the compiler is the culmination of every idea of almost every geniuses' demonstrably proven optimization technique, its basically the collective execution of every single engineering wizard in a singular binary who also knows exactly how to evaluate your code most efficiently almost all the time. (granted we assume all compilers do the same optimizations to low level machine code, which outside of edge cases and small processing differences that's pretty much true)
i just took a look at your code and for some reason the assembly one looks way cleaner and simlper than the c++ one, at least for me. congrats on the readability of the asm version
Well to be fair when writing assembly you obviously want to write as little code as possible, so naturally it's going to be cleaner because less code = less chance for spaghetti to cook 😂
Trying to wrap my head around how confused you would have to be to implement a linked list in assembly, or why you'd implement an allocator for a small dataset with a static maximum length.
@@handleneeds3charactersormore He meant That he isn't able to finish writing up Python scripts in as short amount of time as the creator can in assembly
I’m a bit lost as to why you would need linked lists for breakout. Breakout is a game that could be handled pretty easily using only the data segment to define your static array of bricks and player tokens. Biggest pain I foresee is the gameloop, graphics, and IO but none of that should require dynamic memory.
Sure it might be a bit over engineered, but I had a rough design that I wanted to implement three times - and that included a dynamic data structure. So maybe my phrasing wasn’t accurate, I didn’t “need” a linked list. If I was making a “real” game definitely I’d think a bit more about what data structures I used (:
@@amyshaw893 Yes of course. But it'll need an equivalent amount of bits either way. The only difference is how you interpet them. However, linked lists in this situation will make for more indirection, more work and more memory used. C doesn't have big ints AFAIK, but it does have character strings. These can be abused to do kinda pseudo big ints. Come to think of it, x86_64 asm doesn't have native big ints either right?
@@AbAb-th5qe wouldnt a 2d array need a full byte for each element? im not sure if you can make a 2d array of single bits, plus that doesnt include the array overhead
The advantage of assembly code is that you only write the code that is needed and the assembler turns mnemonics into machine executable instructions. Higher languages rely on libraries which are general purpose, parameterised routines that include a lot more code. Then libraries are written that rely on the inclusion of other libraries... Yes, it makes the coding easier (read "achievable"), but less efficient. Hence we need super-powerful 64 bit cpus and super fast memory just to present a desk top. I taught myself z80 and 6502 code in the '80s and progressed through a career in COBOL and similar 3rd gen languages in the '90s and '00s. I haven't written code in decades. But the fact remains that the nearer you get to the metal the more "immediate" the execution becomes. However, trade that off against the difficulties of coding at that low level (the Roller Coaster Tycoon that others have discussed). But you can write crappy inefficient code in any language, so speed of execution isn't just a property of the language. The driver behind current languages is speed to market, not speed of execution.
>Using a linked list to write a breakout clone What is it with you modern, high level 'programmers' that feel the need to shoehorn random memory structures into your programs? You can write breakout with just statically defined, bss memory - you can even use bits in a calculated grid system for the blocks to maximize cache utilization in the collision detection and make massive games that still run fine. This is the thing about assembly that many people don't seem to understand: you control exactly how complex it is; you control exactly how much useless abstraction you add to your system. It just so happens that simple solutions to simple problems are also usually much faster than complex solutions.
You are right, it was an active decision on my part to increase the complexity. I felt it told a better story of how each successive language made development easier by increasing abstraction, by having a common-ish design across all three. It also helped highlight how low-level and bare bones assembly is.
@@nathanbaggs Maybe so but it also failed to highlight one of the largest benefits of programming in such a low level, namely the direct incentive and ability to write said program in as few instructions/using as little memory as possible. You, in fact, directly contradicted it by exclusively focusing on its flaws. The whole point of programming in assembly, these days, is to write extremely tight code with (optionally) tight memory constraints. Being bare bones is both a good and a bad thing but I saw very little good. In fact I don't think I saw any at all. It's quite one-dimensional, this analysis of assembly programming, and it comes off to me as forced, like you were trying to form the narrative to be only what you wanted it to be. I'm not saying go full jargon but misleading your audience just to tell an appealing story is exclusively targeting the lowest common denominator and is degrading to the heuristic knowledge of people who don't spend their days programming in assembly.
One thing you did in your code that I've never thought about doing is writing out the function logic as a comment block under each prototype on the header file. I could see how useful that would be for other devs who don't want to drive into the specifics of every function, only what they do and return in an abstracted way.
Interesting upload, thanks for this. Assembly language, while extremely simple in it's individual instruction code mnemonics, is incredibly extremely difficult to expertly program in. As you'll know, there's a lot of 70's-90's 'expert-level' assembly language programmers out there. Yes, of course, such expertise will be linked to specific CPU's and their instruction sets. It's also important for every programmer to know that every program in every language out there executes, ultimately, as machine code. You either write your machine code in assembly language (a 1:1 translation using opcode mnemonics and any associated operands), or, you write in a higher level language and put 100% of your trust in your 'translation process' e.g. compiler. Today, assembly language is never used for large projects (for obvious reasons), but when it is used (e.g. game loop optimisation) - and by an expert of on the target CPU - then the best a compiler can do here is to equal the hand-written version... --> Now, with that...if you compile the SAME C++ program with different compilers, you will get very significantly different machine code outputs with each compiler. Today's programmers badly need to think deeply as to why this is, and, what effects it can have on your program (hint: speed, size, bugs)... What this means if that there is very significant room for equally significant optimisation using assembly language.
Great video, this is the kind of stuff I work with daily. How come you keep implementing linked lists? Would a normal array not work fine here? Linked lists are often more trouble than they are worth because of the memory overhead in each element and it is comparatively much more computationally expensive than a typical array.
I went for simplicity over efficiency. I didn’t have to worry about bounds checking, resizing and copying elements (for dynamic array). Just allocate a node and wire up the pointer!
yeah: in ASM the only structure is array (possibly of records). You do not need memory management in ASM. You work on your own private array statically allocated with your program.
@@drivers99 yes sure, index is just a local pointer relative to the array. But higher level structure aren't natural in ASM. Better use data structures better suited to your language. Low-level langage imply low-level data structure.
Wasn't disappointed with this video, great work. I got a class this semester that specialises in the architecture of computing units. It's mainly aimed towards optimisation. Going from single thread unoptimised code to heavily multithreaded, optimised in all aspects, vectorisation, working with cache more effectively, reading less and what we need. Understanding how CPUs manage to do more per clock and how you can help it as a programmer with properly designed code. That's just something awesome. But yeah, you're not gonna expand your for loop, let it read 4 different values behind each other, because it takes three clock ticks to actually get it and work with it, so your code would do nothing. That's just a small part the work compilers do for us and I personally think that is awesome. They are written by smarter, more experienced programmers and are in development for longer than I am alive. No point in drag racing them. I got to say, had one class about assembly and I don't even know where I would start if I were to try to implement something in it, not to mention with GUI. Great video showing that going deeper doesn't always mean faster. Can't wait for the next one titled "I tried to write something in binary by hitting neutrinos with my HDD (just kidding, used Emacs plugin)"
Well if you code in assembly with a c++ mindset no surprise you'll find c++ more comfortable. Same happens if you come from python to c++. Not to care about pointers and memory allocations is a "breath of fresh air" in python after c++. However if you do care about efficiency you'll find python frustrating, since you can't controll what the computer is actually doing. So if you learn the c++ mindset you'll find python extremely limiting. The same applies to assembly: if you wanna squize the last bit of performance out of the computer you'll find c or c++ limiting after assembly. Of course it doesn't really apply to moder PCs but could be a real issue with programing microcontrollers, 8 bit retro computers or other devices with limited resources.
Yeah for one thing I was like why TF do you need a linked list for a breakout game??? For the assembly part you could just do what people do for retro PCs and just take a big chunk of heap memory and slice it up into a memory map for the game to use with pointers for each part, one part of the memory can be for the ball, one part for the bricks, etc, there's no need for a linked list or any sort of fancy data structure like that for this simple type of game...
Many thanks aks for sharing your AMAZING project 👏👏👏🔥✌ Please consider making end-to-end tutorials for the whole project. 🙏 That will be extremely helpful for c cpp assemly learners. Maybe more similar projects in the future Many thanks in advance! 👍
Can’t be disagreed, when I first learnt assembly I fall in love with it, but as I go I was trying to build more complex stuff like floating point arithmetic, and visual stuff it just sucked , because I have to implement everything from the scratch. Any event it’s amazing work you have done , thanks for sharing.❤❤
@@abz4852 oh god, fuck that language it's a very similar experience to what the original comment has described, but it's many orders of magnitude slower and _incredibly_ restrictive
A really useful challenge for me was taking something as simple as a linked list and go from Python to C++ to C and assembly. On the way i dropped a view things like C++ had a dynamic type and a static typed version. C and assembly only had static types. And i always used the the knowledge as well as the generated code from previous versions. This challenge really lets you think about what you are actually doing with high level features.
I found this video extremely useful Nathan, thank you. I had to put a SDL_Delay(1) statement in the running loop as it was impossibly fast to play, and cpu usage was very high - unless I did something wrong? I also had a compiler warning in c_window_destroy line 79. “Potentially uninitialised variable” - fair enough! I commented this line out for expediency. The hardest part of this was installing the SDL lib. I was stupidly trying to build a Win32 using the 64 bit SDL lib - silly me!
If you do not give CPU time explicitly in an infinite loop (for instance by SDL_Delay(1) or any other "sleep" function), CPU will be consumed with 100% (at least on one core), as task scheduler will always give immediate control to your application (unless there are other applications which are in active state and have prio equal or higher than your application).
Despite not writing in it since college when i used these little embedded project boards, i think my experience with assembly is invaluable. It allowed me to better understand how things work under the hood when programming in higher level languages, like C and C++. I would love to program in assembly, but it is way too tedious to do so for the code i write. We should be thankful to the creators of higher level languages who abstracted away the tedium of assembly and made programming much less tedious. Great video, btw!
I'm curious why you implemented malloc for the x86 version? I've done some simple games targeting wasm without libc and had no issue just putting everything into a statically allocated buffer
You’re absolutely right I could have done that. I wanted to try and keep the three implementations similar - C and C++ used dynamic allocation so I wanted to see what it would take to do that in x86.
@@nathanbaggs Conceptually I understand, but as a counterpoint you have programmed in C like a C programmer, in C++ like a C++ programmer, and in x86 like a C and C++ programmer. You've made a good video. I was expecting to see a comparison of programming languages paradigms, and didn't find that.
@@PhilipBarton He also could have put everything into a statically allocated buffer in C and c++. Its not "thinking like a C programmer" to dynamically allocate memory. Its part of writing more than a basic program.
@@khatdubell the simple approach is often the best one, a "basic program" is what you should aim for. If there is no need for dynamic allocation, doing it just makes you code objectively worse.
@@marcossidoruk8033 only using static allocation isn't a solution tho. It still makes things complicated, because you need to separate it into chunks. Same thing with dynamic allocation, using mmap gives you a page of memory (so 4096 bites) that you need to cut into chunks. You could very well just ask mmap for way more memory memory a single allocation and then do your thing. At the end of the day, mmap will return you consecutive memory because of the layer of kernel abstraction around memory.
You didn't need a linked list (an array is plenty for your game) and you didn't need to implement x11 directly. C doesn't provide graphics libraries any more than assembler does so if you allow yourself to link libs in c then you can allow yourself to link them in assembler.
All this is way over my head, I used C in the past but that was in the eighties running on SCO Xenix. But I do remember the code for this same game written in the Basic that came with the first gen Apple 2, I doubt if it was much longer than 30 lines due to the graphics and paddle capabilities that Woz built in when he wrote the language. It ran seamlessly on a 1Mhz CPU with the 32k Ram I started out with.
The asm version appears to run slower than C/C++ versions. That says alot about compiler optimization. I would try turning off optimization, compiling and running to see if that makes a difference
More likely, it says things about data structures or algorithms build into C/C++ libraries. If it was code for code, compiler optimizations on a game like this would be minor.
hey man, first, congrats on making something that complex in assembly without years of experience in it! I feel like you took a very wrong approach to coding in it and C though. The first realization should have been that you don't need a linked list, or a malloc, you need only do the steps required to run the game, just mapping a few memory pages and getting a pointer to the window vram from the kernel is all you should really need (as well as communication messages between the os and you but you had to do that regardless). Ofcourse working without the niceities is tough if you've never done it before so it seems like the only thing to do in x86 assembly is to look at it and start your IDE with a normal language on it, but there are still very good uses for assembly programming, though not directly in assembly. What is done (most commonly in the games industry because that's one of the last places where getting everything out of your computer matters) is you take a very unoptimized problem, you shrink it down through regular optimization, and then you apply SIMD to it. What's that? Yeah there are special assembly instructions a C compiler will never use, unless you tell it to, and even then unless you structure your data right, it won't get to use them. These instructions can process whole arrays of numbers or even matricies of numbers at once, there are instructions for ray intersections, for regex filtering text 16 letters at a time, cryptographic functions, all these can be done by specialized wiring inside the cpu extremely more efficiently then any high level code could. And that's mostly the only place assembly should be used, because as you've discovered, it's a pain. Thanks for sharing it with us!
I might have over engineered the assembly design a bit, which has been pointed out in a few other comments. But I wanted to see how easy it was to create comparable solutions across the three languages, which includes dynamic memory allocations. I wouldn’t consider myself an assembly expert but I’ve read/written enough to get by. So I’m familiar with SIMD, etc.
Every time the ball hits a brick you have to append a 1 to a linked list, this is necessity for Breakout. Otherwise, you can't really call it Breakout.
Love the brevity of your video while also keeping it easy to digest! Keep it up! Also really like the theme that you're using, seems easy on the eyes. Mind if I ask what it is called?
Thought it was gonna be one of those nonsense "writing the same game, using the same source code-ish to see the difference between C and C++" but the fact that you actually leveraged what C++ does so great (like RAII), anonymous namespaces, etc, makes it rather refreshing.
So good to watch it, I wanted to really learn asm, but it's so hard, I do c and c++ for my university's sake but work with python. How much time did you need to master asm? And what do you think should I learn it for cyber security?
This seems to be out of the scope of the video but I'd be curious to see some sort of performance benchmarks in terms of FPS comparison between all of them! Would be cool to see how little or much the pain of low-level programming is for speed.
Language won’t give you any speed benefits considering today’s optimizations within the compiler. Listen to Lex Fridman podcast with Bjarne Stroustrup and he talks about this.
@@jorgeherrera1074 Depends on your compiler, really. For Arm, Intel, Power, SPARC, etc. there's rarely any chance you'll outperform the C compiler. Some lesser-used architectures don't have any good C compilers (or charge a fortune for them), so there are still places where hand optimization is useful. PIC comes to mind here - I don't know how it is now, but back in the day the only free compilers available weren't very good. You could pay for better ones, but it wasn't cheap for a hobbyist. I suspect that's a major reason the ATMega got used for Arduino over the PIC, which was more common in the industry.
and @@jeffspaulding9834 also very good to know that this is not always the case. I'm curious to know what hardware has unoptimized compilers. I rarely write embedded software so hopefully I should be safe using the C compiler most of the time!
@@bren007pie2 PIC is the biggie - if you don't pay for Microchip's compilers, you're stuck with unoptimized code. I looked around and things seem to be improving. Lots more microcontrollers have gcc or clang support these days. Some manufacturers still recommend commercial compilers, but gcc seems to be gaining a lot of traction.
In assembly you have access to all the standard Microsoft libraries and with a decent Macro Assembler like FASM, you have macros to handle those function calls. Moreover something like tail call optimization is usually just a jmp call in assembly, while impossible in C, unless the compiler provides it. Some of those macros are pretty powerful and you can actually be productive in assembly. The main problem is that it's not portable.
Damn I thought you had like 200k subs or even more judging by the qualities of your videos. You have earned your self a new sub Ps could you make tutorials for c++ :(
Thanks for the kind words! I've been considering making some tutorial content, do you have any specific part of C++ in mind you would like tutorials on?
In the '80's it was easy to write apps in Assembly that were faster than C. Since then the microcode in microprocessors got far more sophisticated. The longer pipelines & similar sophistication are things that compiler writers spent a lot of time optimising their output to take advantage of. But you have to think of all that with you are also dealing with the logic of your code. Thats tough.
Always remember the costs associated with the coding and maintenance of the code. But that is part of losing knowledge, people are forgetting the basics learned from the 1960s through 2000. Great video again!
You can use libraries and call functions in ASM. If I'd been writing in ASM, I'd have used SDL and libc. Just because you're writing in one language doesn't mean you can't call functions written in a different language.
Why would you need malloc to code a version of Breakout in assembler? Surely everything would just be statically allocated and you don't need anything more than simple arrays to represent the set of bricks on the screen (e.g. 1 byte per brick with each brick within a grid: 14 column x 8 rows). An early assembly programmer wouldn't even do that, they'd allocate 1 bit per brick. Then you'd first check the location of the ball: ball_y>=brickmap_y; && ball_y
I think I could have been more explicit with my choice of words, I certainly don’t “need” malloc. I had a rough design that I wanted to implement three times and that included something non-trivial like a dynamic data structure.
Come on, you can use any C/C++ libraries with assembly too. Maybe it's not very easy, but coding in assembly doesn't have to mean coding every single part of the code in assembly. For me the most effective way to code something like a game is mix various languages. Where you need high complexity - high level languages, high performance - C++, C, assembly. I found C# is like perfect for some complex (or dynamic) data structures, high-level protocols handling, but it's not good to just push bits from one place to another with consistent timing. C is perfect for pushing bits reliably, but handling complex things with it gets tedious. C++ is something in between. The speed of C, but it's a little easier to add some more complexity without writing too much. BTW, C flavored C++ is a cool thing. You just use C++ like C with namespaces ;) That approach works surprisingly well in some scenarios.
Why would you need a malloc and a linked list for a simple breakout ? You only need a fixed amount of memory to store the level and the graphics. Just use data and bss sections. Anyway I never coded in assembly on Windows but I'm pretty sure there are Windows functions to allocate memory dynamically.
You’re right, you don’t need it, I think I could have been a bit more explicit with my choice of words. Also something I could have been clearer on is that this was written using WSL, so it’s all Linux syscalls.
i might be the old one here but i remember writing a breakout game in ASM and i had no issues with memory to get more banks or issues with the data as i could get away using the video memory instead of an array of blocks. and a counter to know if we ran out of blocks. and it was running just fine - sure there was no windows / gnome (x) to worry about as it was dos based, but if anything it was TOO fast, so had to slow down the bounce to whatever millisec to be playable. (of course C compilers are making much more effecient compiles, but it does not make a difference at such a low complexity game and where you have to slow it down anyway) and we are talking about 8MHZ cpu speed and not 4.2GHZ with 16 cores :) i agree writing the code is easier on higher level languages, but i reject that there is no fun and excitement working in ASM. at least for me it was fun
True. What is hard to see here is the fact that writing in such a low level language as assembler in such a high level operating system feels very obsolete. I also think I sound like the old one here, but when you have nothing but a blazing fast 20 mhz machine and a brand new, 1000$ EGA graphics card, you'd LOVE this low level ability to manipulate any register to your likings, twitching and twisting the bits around, just for this one, little more of speed you MIGHT get out of it. It's like playing with lego blocks, a craft with a very hand made feeling to it.
I think I could have made myself clearer in the video. Instead of “I needed a linked list” I should have said “I wanted to write a linked list” - and the reason for that is I felt it told a better story of how each successive language made development easier. As you and others have pointed out, there are alternative/simpler ways of storing data.
@@nathanbaggs Don't get me (us) wrong we are not here to fight or lecture you :) the mere fact that someone is still attempting to do ASM is great :) But on one thing we are going to disagree :) Actually your attempt did not show the real picture of how each language made development easier. See forcing linked list on ASM is something absolutely not language 'correct' I would say using the standard ways of storing data would have showed how different and what benefits the new languages are bringing. I mean once you had your linked list library, its frankly no different on the surface than calling some high level functions in C / C++ since now you HAVE it thanks to your library. What your approach showed that ASM is capable of having whatever a high level language has, but it does not show the real progress. i mean this is a good example: call cls jmp $ cls: pusha mov ah, 0x00 mov al, 0x03 ; text mode 80x25 16 colours int 0x10 popa ret (copied from stackoverflow for easier reference) this is what you did with the linked lists. :) But now there is no difference between invoking a high level CLS or this here... So in fact you blurred the boundaries :) i think what would have made more sense is to show how you get data in and out from say the graphics card memory to handle collision detection and then show how much easier it is to use an array or a linked list. the same would go for keyboard handling, or writing text on the screen... etc :) anyway, it is a good video, so keep up the good work :) you are onto something here and i am sure great success is ahead of you :)
@@luicecifer I agree, coding in assembly in the day and age when you have layers upon layers between you and the hardware is obsolete for "everyday coding". but it has the benefit of learning how actually the CPU is working under those layers. it might help someone to think when they write their highlevel code. (lets talk about the predictions the CPU makes and calculates ahead just to throw away everything it failed with the predictions - IF statement in a loop for example) For non everyday coding however where every cycle counts assembly is the best friend besides C / C++. (when maybe a millisecond decides between a disaster and a successful landing on Mars - and you can't afford running a multilayered system for limiting errors and resource eating) :) :) and ASM is such a highlevel coding compared to punchcards anyway :D :D
Okay, I have to ask, why did you have use malloc in ASM? It sounds like you litterly reinvented the wheel, because of your familiarity with how you are used to doing things. Having coded in all 3 languages myself here is what I can say. Don't expect any hand holding in ASM, if you're doing things the same way you did it in a compiled language you're probably doing it wrong. Examples are, coding while using a compile anywhere mentality. ASM by definition is machine specific. Your targeting specific hardware, using a specific OS. Once you realize this you will find in every OS a specialized memory management API. You then have to think how that API is meant to be used. Then make it do what you want. At my peak I got to 50/50 when comparing my code to compilers. Half the time I could beat them in both size and execution speed. It only got better if I peaked at their output and used that to optimize mine. You probably have no idea how often compilers tend to add a ton of unessarry stack management. If your good you can manage your entire stack with math and free up your stack frame register to be used as a generic register. C is the baseline I compare all languages against. Its simple no nonesese calls and structure generally makes this one of the simpler languages to work with. C++ is what I use when I need lots of easy to implement data structures. Of the 3 languages this is the one where data management takes the foreground. This might be a bit overkill for a breakout game. As most of your data structures are ideally just arrays. So if I were to equate the languages as tools to move boxes. ASM is using tweasers, C is just picking them up manually, and C++ is the forklift. And don't get me started on what you can do when you realize you can export libraries in c and c++ to be used with ASM, and you can use inline ASM in both C and C++. These languages are litterly interchangeable.
Love the bit about "the assembly can only be as good as i can write it" A lot of people seem to think that writing in asm is racing stripes to make the computer go faster. Humans should do the things humans are good at and leave the things computers are good at to computers.
In the past using inline assemble did help when compilers didn't have the optimization they now have. In some instances a significant performance gains could be done. Usually instead of writing an entire application in assembly you wrote a few specific functions that are imported into C/C++.
but assembly was made for humans to write. it's what the intel manuals for x86 programming cover. people have, and continue to write faster assembly than a compiler. usually because of them making use of certain instructions that the compiler doesnt.
@@minneelyyyy8923 So were punch cards. I don't see anyone stumping for that. As far as a human beating a compiler, maybe on a single function or optimizing work the compiler has already done, but toe-to-toe, human vs machine the machine will win every time on any non-trivial program. i'll bet my lunch money on that.
@@khatdubell punch cards are a funny example considering that no modern computer can even understand them, thats very clearly an old technology. assembly, however, is often benefitial in small amounts. it is necessary, too, for things like osdev or writing low level code for the os.
@@minneelyyyy8923 Compilers will used advanced instructions. It really depends on setting the compiler settings. About 25 year ago C compilers defaulted to the 386 or 486 instruction set, and if you wanted to use the extended instructions of i486, Xeon, you had to enable the compiler setting. The issue with using extended instructions was that a lot of machines had processors that didn't support the extended instructions. I believe today compilers all have the extended instruction sets enabled.
It was introduced in C++17 and was a real game changer for me in terms of API design. No need to bother with out parameters. It combines nicely with if statement initialisers, so you can do: if (const auto v = func_returning_optional() ; v) { }
I am new to programming, but i was wondering if there is a difference if you write in C and link Assembly to your C program to execute as one vs just writing in C? Is there any performance gain that could be noticeable?
It surprises me that you find namespaces an improvement. I would think that the program you are writing is small enough that you wouldn't get many, or even any, naming collisions.
I was writing each solution as if it were part of a larger project, in that sense I couldn't guarantee that Vector2, Window, List, etc names wouldn't clash with another library. So to me the C++ namespace is an improvement as it means I didn't have to add a prefix to all publicly exposed names.
insightful experience. You should try to that similarly using Rust, it's not very different from C++ (you might need to "let go" some C/C++ concepts) but it's interesting language (kinda boring also, but the safety is worth it).
The amount of people in the comments mentioning rust was not unexpected. It’s on my todo list to learn, I want to spend some time with it before I can do a fair comparison
While C/C++ compiler optimizations are usually faster than normal assembly code, note that optimized assembly code will be faster than C/C++ compiler optimizations.
What Theme are you using in this VS editor? I love it but I can't find anything that matches.. infact, theres a lot about your IDE that's different come to think. Can you make a video or point me to something showing me how your IDE is set up? Theme and all?
@@nathanbaggs Ah, well I'm new to VS and generally coding in an IDE so idk what's standard and whats not xD I feel that would make a good video, "x Must Have VS Extensions" or "The x VS Extensions I use" Or something to that effect.
The assembly frame rate is bad because it was a really basic game loop. For C and C++ I’m not sure why, I didn’t notice till after I the rendered video. I think it might be an issue with how I recorded it, lesson learned for the next video (:
@@stephenkamenar yeah that doesn't quite add up lol, even if the code was really bad I doubt the fps would be as bad as it is in the video, then again they did think it was a great idea to have a linked list for something as simple as a breakout clone that doesn't really need something like that in the first place so who knows, maybe there's some other unnecessary thing in that "simple game loop' that's causing it though I couldn't really imagine what 😂
Yeah I was learning zig for highest performance generated assembly, but I've been drifting back to typescript for the comfort and ergonomics. Programming in assembly sounds like major lock-in to your hardware. I should really just be coding in c++ but I've got a huge contrairian streak.
Depends on the application, but a good performing application written in C/C++ probably isn't going to be portable, & it also dependent on the libraries used. For instance if your code used Windows libraries on a Linux or non windows machine, its not going to be portable. Portabile application are usually very limited or are slow if the use cross platform libraries for GUI, or OS specific functionality.
Yes, you're right but if you're using OS specific functionality there's no reason for it to be crossplatform. Like Java for example works everywhere because it makes it really hard to do platform specific things. Obviously you can always for example assume mounted sysfs and your windows build will fail at runtime no matter the language. What's good about C is that you can compile time branch the behaviour with preprocessor which effectively allows you to go crossplatform while using peculiarities of each supported platform. You have to design your application with the crossplatformness in mind from the getgo adding it later would be a pain in a large project.
Interesting that you thought "I need a linked list" I code small games in C and pretty much always just use static arrays I actually dont even know what a linked list is
I can't think of why you'd need a linked list, or any dynamically sized container for that matter, in a game like breakout, but there are definitely uses for it elsewhere. Writing malloc from scratch is one of those, lol. Generally speaking though, linked lists are a terrible idea for cache performance and you're almost always better off using a contiguous block of memory if possible. They are quick to insert and delete things from the middle of the list, but you'd have to do a LOT of inserting and deleting to make it worth the cache penalty. And it takes more memory to store all those pointers. But it's always good to know the pros and cons of the tools at your disposal, std::list is still there for a reason.
Your follow up comment is right, I just wanted to compare the languages and that includes how easy it is to write data structures. If I was making a “real” game I’d consider the data structure more carefully, but for this it was fun to try and use a dynamic structure across all three implementations.
If I wanted to make my own game engine like build but able to use 3d models like Quake/Unreal or something like classic wow and a level editor like trenchbroom, what be the best start for a newbie that never code anything?
If you approached the asm with an old school mindset you would have simply skipped the malloc and linked list for a project this simple. Neither would be necessary. In simple systems we used and reused static buffers defined in the assembly directly, and linked lists if used at all were usually using embedded pointers in the statically allocated objects. Though right enough larger systems typically ended up writing much of the same code a C runtime includes. FWIW once the C compilers evolved enough to generated decent code, everyone, barring a few stick in the muds, switched to using C with asm used only to enhance performance where it was most needed.
Why did you go for a linked list instead of a dynamic array or even a static array in the asm and C programs seems like you did in the C++ program by using std vector even though it seems much simpler and faster?
30 years ago I was writing games in x86 assembly. I was 18 at the time and it was exciting to have a level of performance that I'd never been able to achieve with stock libraries that came with my BASIC and C compilers. But... yeah, that's a lot of extra work. I very quickly switched to writing my own graphics libraries in assembly and writing everything else in C. Kids today have it too easy. I could rewrite that entire project in C# in a weekend.
