How common is this?
-
I rarely do my programming on a VM. Understanding how a VM works is not at all relevant to my problem solving. Memory usage, caching, disk swapping etc. is equally relevant for a non-virtualized machine. Just out of curiosity I would certainly like to understand the virtualization mechanisms provided by modern CPUs - but the documentation is certainly not written for software people! I cannot possibly imagine than more than one percent of all the software people I have been working with has the slightest clue about the actual mechanisms. A few years ago, I bought a pile of books claiming to explain virtualization; they were college level textbooks, giving you an understanding of the real/i> mechanisms at a level that could be compared to your understanding of international politics gained from watching TV newscasts. Fair enough for cocktail party conversations ... I am quite sure that the majority of software people claiming to know something about VMs are not much above the cocktail party level. They probably know what the VM will do for you, but not how. If I brought an architecture reference manual for a recent Intel CPU, asking questions about this and that mechanisms works to support the what, and the consequence of not having the mechanism available, as on older CPU families ... The great majority of software people would be lost - even among those claiming to know what VM is. If you are active in development of the Linux kernel, or writing register-level drivers for Windows 11, you must of course have an understanding of the virtualization mechanisms way above cocktail party level. But that applies to a tiny little speck of the programming world. For the great majority of them, there are far more important skills and areas of knowledge that would make him a more outstanding software developer.
I should have made myself more clear - the language's virtual machine. All higher-language programming is done to a "virtual machine" of some type. Even C assumes certain things about the hardware it is running on. It is in this sense that I refer to a virtual machine.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
-
I have met people who had to be able to imagine the microcode, and the specific signals sent to the various units of the CPU, to feel that they had a good grip on the software. Knowing the nature of static vs. dynamic RAM is essential to understand the effect of cache size on performance. When compilers started using optimizing techniques (that was with Fortran II, wasn't it? Long before my time :-)), I lost grip on how the assembly code generated from my high level code will look. The optimizer moves stuff all over the place, may remove significant parts (e.g. as unreachable, or because that subexpression was calculated earlier so it is available in a temporary location), and so on. Donald Knuth didn't trust any high level concepts. If he had, maybe his Bible would have gained a large following. It ended up with his Bible being something that sits on the bookshelf. To learn algorithms, you rather go to books based on concepts relevant to the programmer's problem, not to the CPU designer. Gradually, I have come to trust the compiler. I know that not everyone does: In my scrapbook archive, I have preserved a discussion from a network forum where this one guy fiercely insisted that the VAX C compiler should have generated a different instruction, which this debater thought more appropriate. Others pointed out that the actually generated code was faster, but the debater stuck to his conclusion: The compiler was defect, generating inappropriate code. Yet ... I am sometimes shocked by how willingly youngsters even with a university degree accept that "If you just flip this switch and push that button, it works - but I have no idea of why!" I still maintain that you should understand what is going on at least one level below the one you are working on. The thing is that today, I work at least two levels up from where I was as a student. Microcode and assembler is way below my current programming problems. I relate to objects and structures and parallelism, not to bytes and instructions. Say, subclassing and superclassing; that is understood conceptually, not as how they map to machine instructions. Not even how they map to C! My first encounter with C++, in my student days, was a compiler translating C++ to K&R C code, which required a second compilation pass. I enjoyed it then, but nowadays, I no longer find it worth the effort. Same with overloading: I learned how the compiler generates method labels based on the argument classes. Today, I know that the problem is solved; I have to know the rules for
What you say is true for all technology. We all use it, mostly with only a vague idea of how it works "on the inside". This is one of the advantages of componentization. Where optimizing compilers are concerned, I have learnt to trust them as well. They are merely the latest in a "chain of trust" stretching from the CPU hardware through the microcode, etc. Just as very few of us build our own CPUs, very few of us manually optimize our own code. As for Knuth, I must disagree somewhat. My copy of Knuth gets used a few times a year - not for the MIX code, but for the description and specification of algorithms. I find his language to be clearer than that of many authors who white books with titles like "Algorithms in <language of the month>", and usually with fewer errors. On one level, I couldn't care less if my code were executed by tiny elves as long as they executed it correctly. On another, I share your shock at the lack of curiosity about the inner workings shown by so many young'uns. EDIT: fixed grammar & typos. :-O
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
-
One of the things that really helps me when coding in C++ with templates is I can easily visualize the result of the template expansion/instantiation as raw C++ (no templates) When I'm coding in C++ I can visualize the equivalent C as I'm coding. I can also to a degree, visualize the assembly. Not in any specific sense, but in a sort of pseudo-code like "I know when we're doing a shift, an add, and a push here" kind of thing. I do this to a lesser degree in C# even, when I'm considering performance. I think about C++ code required to get it to do the same thing - but like I said to a lesser degree. Do you do this? I'm just curious. It feels like such a blessing sometimes.
To err is human. Fortune favors the monsters.
I visualize the happy faces of my customers when they're using my software :D
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
I visualize the happy faces of my customers when they're using my software :D
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
I would rather visualize my happy face when they pay for the software!
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
-
One of the things that really helps me when coding in C++ with templates is I can easily visualize the result of the template expansion/instantiation as raw C++ (no templates) When I'm coding in C++ I can visualize the equivalent C as I'm coding. I can also to a degree, visualize the assembly. Not in any specific sense, but in a sort of pseudo-code like "I know when we're doing a shift, an add, and a push here" kind of thing. I do this to a lesser degree in C# even, when I'm considering performance. I think about C++ code required to get it to do the same thing - but like I said to a lesser degree. Do you do this? I'm just curious. It feels like such a blessing sometimes.
To err is human. Fortune favors the monsters.
I have never looked at assembly code, so I can't visualize it even in pseudo-code, but I have been developing an interest in learning the basic algorithms for byte manipulation just for fun and to perhaps optimize code better. C? It was my first real love in programming languages because it satisfied my inner megalomaniac. With UNIX environment variables and C, I could rule the cyber world (muah-ha-ha-ha!). But that was ages ago - back when C++ was just a baby and not well loved. We were creating objects in C and saw no need for a new language to do that. So I image that if I bothered with C++, my answer would be yes, because I'd be learning C++ through the lens of C programming, which is how I expect to learn Rust (which is a just for fun thing I'm going to do). I'm a php web developer, which is pretty much as far from C as one can get. It's a 'forgiving' language, which is to say, it won't let you (fill in the blank). It assumes what you want and does that, even if what you want is an endless fork loop (lol). There is no declaring of variables, no acquisition of memory, no requirement for garbage collection most of the time - you can even have variables that are one type in some cases and another type in other cases. It's very different from C. I have no experience with C# and wonder how like C it is. I would learn it just to see (no pun intended), but I think I'll learn Rust instead. As to the unusual nature of this, I'm curious to find out, but I do think it rather rare. It is what I would look for if I were ever in the position of hiring.
-
I have a good sense of what's happening underneath and will think about it if it seems important. I never coded in C but spent a lot of time in a proprietary, procedural language that might be described as a cross between Modula and a stripped down Ada. We sometimes implemented polymorphism, inheritance, and encapsulation manually, so how OO languages did it wasn't a surprise. Having to parse and instantiate the code for templates significantly improved my understanding of what was going on there. My most recent experience actually writing assembler was on the PDP-10 😲, but what happens in the depths hasn't changed much. Once in a while, I'd like to step into x64 assembler to see what the O/S is doing, but I can't follow it very well. Maybe someday it'll be important enough that I get my butt in gear and dig into it.
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing.I have a vague memory of working with the older Visual Studio versions (pre-. Net), and it provided a view of the actual machine code as you were debugging, and you could step through at that level. I found that quite useful at times. Is that still available when working with C++ in VS? It's been a long time since I worked with that...
-
I have a vague memory of working with the older Visual Studio versions (pre-. Net), and it provided a view of the actual machine code as you were debugging, and you could step through at that level. I found that quite useful at times. Is that still available when working with C++ in VS? It's been a long time since I worked with that...
It exists for C++ in VS 2017 (what I'm using at present for maintaining an older project) - Debug | Windows | Disassembly. I don't know if you can do the equivalent (see the IL?) in C# or similar...
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
-
I have a vague memory of working with the older Visual Studio versions (pre-. Net), and it provided a view of the actual machine code as you were debugging, and you could step through at that level. I found that quite useful at times. Is that still available when working with C++ in VS? It's been a long time since I worked with that...
It's still there in VS2022, and you can step into code for which you don't have the source.
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing. -
One of the things that really helps me when coding in C++ with templates is I can easily visualize the result of the template expansion/instantiation as raw C++ (no templates) When I'm coding in C++ I can visualize the equivalent C as I'm coding. I can also to a degree, visualize the assembly. Not in any specific sense, but in a sort of pseudo-code like "I know when we're doing a shift, an add, and a push here" kind of thing. I do this to a lesser degree in C# even, when I'm considering performance. I think about C++ code required to get it to do the same thing - but like I said to a lesser degree. Do you do this? I'm just curious. It feels like such a blessing sometimes.
To err is human. Fortune favors the monsters.
-
One of the things that really helps me when coding in C++ with templates is I can easily visualize the result of the template expansion/instantiation as raw C++ (no templates) When I'm coding in C++ I can visualize the equivalent C as I'm coding. I can also to a degree, visualize the assembly. Not in any specific sense, but in a sort of pseudo-code like "I know when we're doing a shift, an add, and a push here" kind of thing. I do this to a lesser degree in C# even, when I'm considering performance. I think about C++ code required to get it to do the same thing - but like I said to a lesser degree. Do you do this? I'm just curious. It feels like such a blessing sometimes.
To err is human. Fortune favors the monsters.
I used to think that way about memory layouts in C/C++, but strings in the newer languages where everything wants to be on the heap make it kind of pointless. I trust the optimizers in the compilers for the execution flow. (Unless it is a C compiler from DEC where I recommend /DEBUG to disable optimizations)
