3 ms·

I swear, as a C#/Java/Javascript developer, reading stuff like this just makes me feel like a shitty developer. I know I'm a very competent programmer and arch

by npinguy 13y ago

I swear, as a C#/Java/Javascript developer, reading stuff like this just makes me feel like a shitty developer. I know I'm a very competent programmer and architect but I feel like I could not grasp this kind of low level optimization even if I tried.

com2kid 13y ago
Read about how the C# compiler creates Lambdas. Learn how eventing really works. Learn what your LINQ code is rewritten into. A good C# developer knows the runtime and their compiler, the same way a good C++ developer does. Yes there is a performance gulf between what a good C# programmer can do and what a good C++ developer can do (although the size of that gulf is an argument for another day!), but there is also a huge performance difference between what a good C# developer does and what an average C# developer does. As an example, my team has a log file that is consumed by other multiple teams. Log file parsers have been written in either C++ or C#. The log file has a bunch of discreet entries in it, each one of which is independent of the others and measures in the tens of bytes. One of the C++ parsers tries to read the entire log file it at once. It is dog slow and just chokes on larger files. One of the C# parsers relies on the file system to predict future reads and just pulls the file in entry by entry. The C# parser is faster and doesn't have file size limitations. (On a related note, I have worked with C++ UI frameworks that are heavier weight than C# UI frameworks!!) My point is, a good developer is a good developer, independent of the language. (That said, some of the analysis of cache performance impressed me, instruction count is not everything!)
breckinloggins 13y ago
Trust me, if you're really a good developer you'd be able to swap all this stuff in your head in a reasonable amount of time. For example: I'm not generally a Java guy and I'm not an Android expert, but I once had to create an android touch interface to some custom hardware... and it had to run on one of the first "embedded tablet-like" systems available (this was 2009-ish). In a month or so, I went from knowing nothing about Android and being extremely rusty with Java to: - Doing nifty tricks in Java to make code DRY and maintainable - Writing a fancy flashy Android app - Using the NDK to write a native component that integrated the app with a couple of device drivers - Deeply investigating the performance characteristics of the Dalvik VM and tuning all sorts of things (both in the OS and in my code) to keep things working smoothly Could I do any of this again right this second? Nope. I've moved to other projects and other technologies and all this has been swapped out of my head. But the point is that I could get back there again if I needed to. As a "good developer", you would no doubt experience something similar in this situation. If someone sat you down with a poorly-performing game, some C++ code, and pointed you to enough reference information and profiling tools, in a few weeks you, too, would be talking about cache misses and alignment boundaries and SIMD intrinsics, and... The funny thing about tech jargon is 99% of it sounds like gibberish even to those of us who've been there before! Don't be too hard on yourself :)

by npinguy 13y ago

com2kid 13y ago

Read about how the C# compiler creates Lambdas. Learn how eventing really works. Learn what your LINQ code is rewritten into. A good C# developer knows the runtime and their compiler, the same way a good C++ developer does. Yes there is a performance gulf between what a good C# programmer can do and what a good C++ developer can do (although the size of that gulf is an argument for another day!), but there is also a huge performance difference between what a good C# developer does and what an average C# developer does. As an example, my team has a log file that is consumed by other multiple teams. Log file parsers have been written in either C++ or C#. The log file has a bunch of discreet entries in it, each one of which is independent of the others and measures in the tens of bytes. One of the C++ parsers tries to read the entire log file it at once. It is dog slow and just chokes on larger files. One of the C# parsers relies on the file system to predict future reads and just pulls the file in entry by entry. The C# parser is faster and doesn't have file size limitations. (On a related note, I have worked with C++ UI frameworks that are heavier weight than C# UI frameworks!!) My point is, a good developer is a good developer, independent of the language. (That said, some of the analysis of cache performance impressed me, instruction count is not everything!)

breckinloggins 13y ago

Trust me, if you're really a good developer you'd be able to swap all this stuff in your head in a reasonable amount of time. For example: I'm not generally a Java guy and I'm not an Android expert, but I once had to create an android touch interface to some custom hardware... and it had to run on one of the first "embedded tablet-like" systems available (this was 2009-ish). In a month or so, I went from knowing nothing about Android and being extremely rusty with Java to: - Doing nifty tricks in Java to make code DRY and maintainable - Writing a fancy flashy Android app - Using the NDK to write a native component that integrated the app with a couple of device drivers - Deeply investigating the performance characteristics of the Dalvik VM and tuning all sorts of things (both in the OS and in my code) to keep things working smoothly Could I do any of this again right this second? Nope. I've moved to other projects and other technologies and all this has been swapped out of my head. But the point is that I could get back there again if I needed to. As a "good developer", you would no doubt experience something similar in this situation. If someone sat you down with a poorly-performing game, some C++ code, and pointed you to enough reference information and profiling tools, in a few weeks you, too, would be talking about cache misses and alignment boundaries and SIMD intrinsics, and... The funny thing about tech jargon is 99% of it sounds like gibberish even to those of us who've been there before! Don't be too hard on yourself :)