Slashdot Mirror
Why Learning Assembly Language Is Still Good
nickirelan writes "Why Learning Assembly Language Is Still a Good Idea by Randall Hyde -- Randall Hyde makes his case for why learning assembly language is still relevant today. The key, says Randall, is to learn how to efficiently implement an application, and the best implementations are written by those who've mastered assembly language. Randall is the author of Write Great Code (from No Starch Press)."
Assembly is great because you can kill any linux system you got ssh access to using assembly.
9/11: Never forget it was a false-flag operation
Also, don't forget, a good deal of programming is still done in assembly. Both in a job I've had coding stuff and in my current research (crypto), I did/do a lot of assembly programming. Yes, learning assembly will make a better programmer out of those who never will code assembly again, but for some people, assembly is a valuable and often-used skill
It's a shame that schools are phasing assembly classes out of their computer science curriculums. If anything, it makes for a great foundation on which to learn more modern languages while teaching students things about computers that they probably wouldn't take the time to learn otherwise.
Right. Because after reading that article, I thought, "Boy, if *I* was a CEO, this is how my guys would program everything." Actually, he says in there that writing everything in Assembly is not for every project.
So what's great about it is that if someone is looking to make a step to become a better programmer, this would be a good direction to check out so that you truly understand your code. If you are happy being a VB code jockey (or any code jockey for that matter) then rejoice! and don't take the time to learn Assembly.
Random Musings
I've programmed a few embedded systems in assembly and it's not very fun at all.
To make matters worse, each CPU has it's own instruction set, and special set of commands that you must learn before you can even sit down and start writing code.
With C++ or at least a C compiler, you don't need to worry about so many implementation details. You should only resort to assembly if you absolutely, must have the performance required. Maybe the author of this article forgets how difficult it is to debug assembly code, or how difficult it is to implement abstract concepts such as OO at such a low level.
I don't agree at all that writing "efficient code" necessarily creates better code. Writing "clearer" is better from a quality standard.
We have compilers for a reason, to produce assembly code as efficiently as possible for a higher level language. Most 99% of the time, the compiler will optomize the code just as well, or better than you can.
I would still recommend learning assembly language to C++ programmers simply so they understand how the computer is actually working. But to require anyone to program in assembly requires a great deal of justification.
Absolutely.
Disclaimer: I learned to debug before I learned to code.
With extremely few exceptions, machine code performs exactly as advertised. When things are not exactly as they should be, it helps to be able to see exactly what is going on.
Performance is much more a matter of structure (exponential complexity) than language (poor linear complexity). As to level, "high level" languages limit you to their implementation of a few concepts. Depending on where the heavy lifting is, Perl could easily outperform optimized C.
I'll put my crudely coded Javascript quicksort algorithm against your finely honed 100% assembly bubblesort algorithm any day. Not only will my algorithm beat the pants off of your algorithm, but I'll also code it in far less time and with way fewer debugging sessions than you would.
You're on. After my exams are over, I'll code a bubblesort algorithm in assembly language. I wonder how large the dataset will have to be before you win? Mail me.
What platforms would you use to teach assembly?
Intel could give many kickbacks to university programs, but they appear to get criticized for chips with too much baggage and backward compatability.
The RISC PowerPC processor has potential, but the number of consumer desktops with it has been on the decline (Is anyone but Apple left?). Computers might be too expensive for some students.
A Palm Pilot / Handheld sounds like a great choice to me. They're cheap and can be synced with whatever consumer desktop the user has (I can't imagine coding assembly in Graffiti). The limited hardware is probably a plus for academic purposes.
I think this fellow makes some great points, but what platform and tools would you choose to learn assembly with?
While the majority of the Unreal engine is C++, we often write assembly-code versions of critical functions for specific platforms. Of course this is done after the C++ versions are tried and tested, and the bottlenecks are idetified.
To take full advantage of processor features like SSE or AltiVec you don't really have a choice.
For example, UT2004 contains SSE and AltiVec assembly versions of some of the vector and matrix manipulation functions, some of the visibility culling code, etc. The amount of work Dan Vogel put into this kind of optimization is one of the reasons that UT2004 runs better than UT2003 on the same hardware.
Learning assembly language is useful, as it's sometimes the right tool for the job.
Got my education in mechanical eng. once upon a time but was able to take a course on uprocessor applications and then ucontrollers (8bit) for robotics. No high level language here. Just straight Assembly code to fit in 32K of memory. You'd be surprised how much you can fit in there. Programs were fast and had to be efficient and I learned alot about architecture, as much as a mech eng could of course.
I see very few links between the way I code in assembly, and how I write the higher-level languages. Yet according to this article I should have the makings of a guru. Where am I going wrong?
Presumably everyone understands binary encoding, shift right and left instructions, and the like? Anything much beyond this is liable to be very architecture-specific - which is bad. I look forward to the day when I can choose between a number of architectures and run the same open-source programs on each. I loathe X86, and I dislike apple for other reasons.
Perhaps we become more rigourous by writing assembly for small systems - with very few resources. But beyond this, I can see no real advantages to learning assembly.
I regard myself as a good programmer, but I see my strengths as being clarity of expression and design.
Skywolf
I think learning compilers and how they will take your code and mangle it into machine code is more important than learning assembly, specifically. Building your own compiler will require you to learn some assembly (or at least the notion of it) which is sufficient for this purpose.
If you never learn assembly you will never have a chance of understanding what is happening to your data and how your memory is structured. While this may be fine for a VB programmer, and in general application programmers, if you want to graduate and become a system programmer, you need to know this information. A drawing with a box in it that says 'class A' and another that says 'heap' isn't going to help you if you want to write a memory manager or a real file system driver. While you may say this is a job for senior programmers, I would counter that I think education should be progressive. College courses should give you the basics so that you can learn what you need in a certain instance. Noone is going to expect a programmer to know the entire application being developed the first day on the job (or sometimes even the language being used!). But if the programmer doesn't have the basics to learn further, when he is told to do something that even remotely borders system programming he will respond "My college said assembly programming wasn't important, so I just skipped trying to understand how a computer works. But I know C#, Java, and PHP!". And the response "Thats helpful. How about you go and make a web page for the project instead, ok"
However, My most sought after skill with my peers was not debugging programs, but using DOS debug to hack around the copy protect schemes in use at the time for various apps and games...
From excellent karma to terible karma with a single +5 funny post...
I myself have learned two and a half different languages at Ohio State and am trying to find time this summer around work to learn a third. To be honest it is almost a "cool geek" thing for me now. I mean everyone and their mother knows C++ or can create a website. Those just aren't as geek as they used to be.
The two u-controllers (microcontrollers for the slow people) that I learned assembly on are the Motorola 68HC11 and on a fairly standard PIC, which one exactly I worked with eludes me at the moment. The half of a language I know is from the MIPS64 family of processors. I only know "half" because I sort of picked it up as a result of another class and have never actually used it myself.
The language I am hoping to learn is the x86 assembly language. It seems to me that of all the u-controllers and processors the one that is by far the most common is the x86 architecture. I can think of several good reasons for individuals to learn assembly language:
- Quicker and Neater then most compiled codes
- Above makes them better for fast embedded systems
- They teach good programming skill
- Can be more powerful, especially when you know how to use it
It isn't exactly as much needed since most u-controllers have C++ compilers written for them. However, sometimes this compiled code is not as fast if it would have been written in assembly by the user. I hope for the sake of programmers and Electrical/Computer Engineers (like myself) that assembly stays around for a long time. It is still the basis for design of any microprocessor and so long as they are using assembly at a basic level, then people need to know how to use it."Some days you just can't get rid of a bomb."
I wonder how large the dataset will have to be before you win?
:) For a large, random dataset I think I'd win out on that one. Check out this sorting algorithm demo page (uses Java applets). Looks like the Shear sort kicks ass over all of them.
Yes, this really is the crux of it all and I left that out. I participated in a very interesting challenge to generate 10 unique random numbers in a scripting language. The goal was for minimal time. As it turns out, a simple array check of whether or not the number has been included worked the fastest due to the fact that you're generating only 10 numbers. As soon as it got up to 100 or more, the array approach O(n^2) broke down.
So for a small dataset, I'll award you your prize already.
Want to improve your Karma? Instead of "Post Anonymously", try the "Post Humously" option.
In this case I think the reason was the system having to load the binary vs. the script interpreter already being resident in memory. The start up overhead dominated the actual runtime overhead - binary searchs are very quick.
Having said that, knowing assembler is useful because it teaches you how the machine works.
However, most modern compilers can generate code that is much faster than handwritten assembler - especially because they know how to take advantage of the specialized processor architectures (hyper-threading, pipeling etc).
...richie - It is a good day to code.
I've been reading this site since it was chips n dip, but this is the first time i've ever felt the need to comment.
I can't believe that any developer could write and code without some knowlege of ASM. Disclaimer: I'm self-educated, so have no bias except my own.
More importantly, if you don't know ASM and can't understand machine language, you'd never get through Knuth's tome "The Art Of Computer Programming".
In my opinion, this is the most important work ever written in our field. Any developer worth his/her salt should have at least read and understood these books, and completed at least the simple exercises.
the examples in tAoCP are written in machine language for a fictional machine, but the depth one learns by reviewing what that machine does with its data is important in any project.
I've never programmed professionally in ASM. infact, i usually work in Perl/PHP/Python. But i would not be able to write quality code in those languages if my mind was not constantly thinking of the machine. After all, i'm a computer programmer, not a linguist or scientist.
Not knowing assembly, or at least having some idea as to how a computer processor works, would make a programmer useless in my eyes. leave them to Access or VBA, and leave the coding to us pro's :)
I beleive that ASM should be taught first. If you can't understand ASM, you'll neer be a good programmer, so why bother learning Java/C++ or whatever? would you trust a doctor who didn't know how the body works?
drewcOpen Source Business: The Tech Co-op
Drew Crampsie - Software Developer
Open Source Business : The Tec
Given the way processors are pipelined, you take such a hit for any kind of function call compared to a set of arithmetic operations that the only way to go is to call functions on arrays or slices of arrays to process batch of samples at a time. If you implemented a digital filter by calling a function for each sample you want to process, that is going to be slow, while if you call a function for batches of 1024 samples, you are really pretty insensitive to the function call overhead. If the function call overhead is high, just make the batch size bigger.
This arises in other situations: for operations over a network it is recommended to make your transactions blockier or chunkier; for raster graphics, the naive Windows SetPixel() command is slow compared to CreateDIBSection().
I'd love to see a return to applications that were under 100K
No kidding. I'm not a programmer, but this guy writes little helpful applications in assembly that are like 20K. In this day and age, I'm impressed when anyone writes anything that can just fit on one CD-ROM.
It's easier to wear the spandex than to do the crunches. --David Lee Roth
>
// in // out
++(char *) 0xb0000;
--(char *) 0xb0000;
Not printf(), but hey, it uses the (monochrome) text screen...
>
(Holds AM radio next to motherboard, listens to the bits going by)
>
Oooh, those are the worst.
>
Use SmartHeap.
>
Those are pretty much axiomatic at this point.
Great symphonic programming masterworks will always be scored in high-level languages. But there are those of us minimalists who thrive on doing as much as we can with as little as possible. Writing a tightly-orchestrated fugue for an eight-bit microcontroller in assembly language is an art form I shall never grow weary of practicing. With a 2K program space and maybe 128 bytes of RAM, every single note must contribute to that ephemeral interplay between space- and time-efficiencies. Those of you who do this for a living will know what I'm talking about. To those just entering the field, I hope you seize whatever opportunities you can to learn assempbly language -- especially if it's for a low-level controller. You may become hooked for life!
For some reason I have a strange desire to teach someone 6502 assembly language.
Maybe you are simply a teacher. I'd say just do it. I avoided college for 10 years because I simply hated being a student. Then, my wife practically forced me to go so I could get my degree and start teaching. I admit that I hated the undergrad junk, but now I am much happier to be in an academic environment than hacking away in some company.
Also, there's the Internet. To this day, any search for my nick (kainaw) still turns up "Kainaw's Amiga Internet Guide" - a guide to getting an Amiga on the Internet when all we had was SLIP over dial-up. Maybe you could write a good guide to 6502 assembly and be surprised when someone calls you in the middle of the night with a strange assembly question.
The previous comment is purposely vague and generalized, but all of the facts are completely true.
Actually, there's a Perl module that does this. But if you wanted to write said C program from scratch, it could take you a while--writing the Perl program would be much faster. And then there's the choice of algorithms involved. Have fun writing your own sorting functions in C, your own regular expression library in C, your own arbitrary precision number library in C, your own reference-counting garbage collector in C, your own closures in C...
:)
Of course, there are other pre-existing C libraries you could use that do all of these things, but there's no telling whether or not they're faster than what Perl uses internally, and since you're re-implementing everything in C anyhow, you might as well just write your own!
So the point I'm trying to make here is this--Perl is convenient because it has all these things written for you and integrated together. Sure you could write a C program that does the same thing, but you'd end up re-inventing the wheel many times over, and you'd have to work hard to make it a better wheel.
Or you could target Parrot instead, for a lot of things it's already faster than Perl. It also has a JIT compiler, so who knows--it might generate some code here and there that's faster than what your C compiler generates.
pb Reply or e-mail; don't vaguely moderate.
I think coders are more efficient in assembly because they don't want to have to write 54 lines of code to do something when if they consider the problem they are solving, they could write it in 10 lines.
To sort 3000 bytes of random data it takes 5.4 seconds on a P4 1.8Ghz while running in debug.exe under Win2K. That's 1.6 million comparisons (of AL to AH) per second. I wonder how long that would take on a Javascript quicksort implementation!
Every shred of C he's ever written is absolutely unmaintainable. It's just horrible.
The answer to the question "Is assembly language faster than C?" is the same as the answer to "Is C faster than assembly language?": "No." My point is that there's no magic bullet. The article was not nearly balanced enough to be considered correct.
Passing 10 argument is bad regardless of the performance issues. These students are making a much more fundamental mistake: they're not dividing up the problem properly into easy-to-understand pieces.
A useful analogy (but don't take it too literally cause I'm oversimplifying it): verbs in natural languages never have more than 3 arguments (subject, direct object, indirect object). If you find yourself crassly exceeding this, you need a justification.
Are you adequate?
I tried learning assembly language, but the I can't find ne place that will really explain to me the details of how it works, I'm afraid I don't know enough of the computer engineering side of it to understand the language. Whats a good place to start, wheres a good tutorial or book? Thanks.
Turns out I was overruning an array, and the static strings for the debug printf()s gave my process just enough space that it stopped trying to trash another process' memory (just its own).
Luckily, as a former assembly language programmer, from the mere change in behaviour, I had an inkling of what was going on...
--
Want to improve your Karma? Instead of "Post Anonymously", try the "Post Humously" option.
Knowing more is almost always better then knowing less, but I'm still going to try to disagree with you. The problem is that the breadth of computer science has grown so in the last 30 years that there is almost always a 'Guns vs Butter' choice to be made in the course of an education. The time I spent on exercises in assembly language was time I wasn't able to spend on algorithms for computational biology and visa versa.
A few years ago I worked with a gentleman who had graduated from a trade school. He was a generally sharp programmer, but he really put me to shame in database design and SQL. He had completely internalized the relational model, and could write a query in five minutes that was an order of magnitude faster a query I'd taken an hour to come up with. On the other hand he had no idea how floating point numbers were represented in the computer (he assumed everything was BCD). In database design there are so many levels of abstraction between you and the hardware that
understanding the CPU architecture is of very limited utility.
A computer is nothing more than a very fast player piano, and nothing less.
Simple, huh? But it is understanding this that is key. First off, how a player piano works: there is a reel of paper, the "roll", upon which is impressed, via a series of holes, one for each key, and a few for pedals - the notes which will be played. It is pulled past a row of vacuum air valves by a clockwork or electric motor. This same motor drives the pumps for the air system, when a hole passes, the note is played - how long the hole is determines how long the note is held down for. Other holes determine how long the pedals are held for. The roll of paper unrolls at a constant rate. I believe there were "operator" knobs to set this rate for various rolls, as instructed on the rolls.
And that is how one of the Victorian-era programmable machines worked. This is all a computer really is. This is how a CPU works.
Imagine the roll of paper with its holes, each "row" on the roll being one "address" in this very long (but finite) amount of "memory". At each address, or "row" of holes, is encoded an "instruction", consisting of a bit pattern, that is read by the "CPU" (the valve system), which "executes" the command to the rest of the "system" (keys and pedals). Then on to the next "row"...
This is how a CPU works, and it is how assembly works. The CPU has a bunch of address space, and it is mapped to the addresses to which the memory can be instructed to read or write. The clock on the system causes the CPU to advance states in the system, which increments an address counter, typically called the "instruction pointer" or IP. This pointer is set to a value indicating the starting address of the code. When the CPU is told to "run" the code, the instruction pointer is advanced one address at a time by the clock. At each point, the CPU reads the data at that address. Let's say each opcode in assembly for our fictional CPU is one byte in length. Some of these opcodes say that the next byte might be data, or the next two bytes are data, or no bytes are data (the next byte is another opcode). Each of these codes causes the CPU to read the instruction, switch logic gates via electricity in the electronics so that a logic path changes to read the next bytes as needed and assign them to whereever (other memory, a register, a pointer). Some of these opcodes may be jump (JMP) instructions, in which the next byte or so represents an address to which to set the instruction pointer (thus, unconditional branching). Other opcodes may indicate conditional branching, in which the processing the CPU does for such an opcode reads certain flags, memory areas, or registers, and then jumps (or not jump) to the specified address based on the boolean outcome of the comparison.
You should now be able to see how stringing a series of opcodes (bytes) and data (more bytes) together, with the CPU stepping through it, electronically and electrically reconfiguring itself to shuffle data (which is represented by electrical logic states, like +5V=1, 0V=0, in electronic circuits - it goes deep, very deep). Name the opcodes according to what they do, and how many bytes afterward are "arguments", and there is how a CPU works, at the basic level. Just like a player piano.
All the CPU is doing is slogging through a whole mess of bytes and interpreting them to electronically re-arrange itself to perform calculations. There are further refinements of this - my explanation of how a CPU and assembler works is only a very basic one (I can't write a book for ya, can I?). One such refinement (and incrediblely, none other than Charles Babbage implemented a form of it in his plans for the Analytical Engine) is the concept of "microcode". Microcode is essentially assembler for which the CPU is pr
Reason is the Path to God - Anon
An earlier poster mentioned how such a skill can help you find compiler bugs. This can be the case, but it is rare; I have located two such bugs in 20 years of programming. A more common use is to locate bugs in your code. When your brain refuses to see the missing braces around the wrongly indented code, or an spurious semicolon at the end of an if or while statement, reading the generated assembly code can save some extra hours of frustration. You will be able to see that the code the compiler generates differs from the code you think you wrote, and this will point you to the bug's location.
As I argue in Code Reading, other cases where reading assembly code can be of use are:
To read compiler-generated assembly code you need:
Obligatory "hello, world" program written in i386 assembly:
Diomidis Spinellis - #include "/dev/tty"
In an article I read the CEO of FSecure was quoted as saying the biggest recruitment problem is the lack of assembly language teaching in universities these days.
I guess it helps if you are in the business of making bugs, too.
I'm sorry if I haven't offended anyone
Hm,
... that bothers me.
... and here he says, well its anyway better to just make a factor two or three improvement? See now here:
... He thinks making a program 2 or 3 times as fast makes the difference of successfull or not. But the same approach by using hardware he finds inappropriated.
... thats not a big difference. Great software on those low performing machines where most of the time games. And the games clearly where written in different perspective. No one said: I want it looking like this: make it so. Programmers and game designers where more or less the same persons, so they could write good code yielding good games by experimenting. How if we make thagraphics like this? How does it look and feel? How if do it like this? Remember Doom? Doom was great because the coders found a simplified way of 3D scene generation (raycasting). Thats an algorithm. Thats data. Thats an idea on how to transmorgrify specifications into a program where the product manager does not see that his spec was transformed. Because it looked like he expected.
seems that article is a try to hype the book: "Write Great Code". While some few small trues are in the articel msot of its conclusions are false conclusions
Some random quotes:
It's all well and good to say, "I'll just find a better algorithm!" However, finding and deploying that algorithm, if one actually exists, is another matter.
A programmer able to find a better algorithm is also able to deploy it. Why does the author think different there?
say, going from an algorithm with O(n^2) performance to one with O(n lg n) performance, but the truth is that most of the time a constant factor of two or three times improvement, applied throughout a piece of software, can make the difference between a practical application and one that is simply too slow to comfortably use.
Hm, isn't that a little contradicting to the authors rant? He argues that the programmers are so poor, they can not even find more efficient algorithms
Advances in computer architecture have exacerbated this problem--for example, you might hear a programmer say, "If this program needs to be a little faster, just wait a year or so and CPUs will be twice as fast; there's no need to worry about it." And this attitude, probably more than any other, is why software performance doesn't keep pace with CPU performance.
Ooops: he clearly does not know what programming is about
Well: but this is the most clear statement that teh author has really no clue how two write efficient software on old hardware:
Programmers were doing great things with software back in the days when their applications were running on eight-bit 5MHz 8088 PCs; the same techniques they used to squeeze every last bit of performance out of those low-end CPUs provides the key to high-performance applications today. So, how did they achieve reasonable performance on such low-end processors? The answer is not a secret--they understood how the underlying hardware operated and they wrote their code accordingly. That same knowledge, of the underlying hardware, is the key to writing efficient software today.
Assembly language or C
Most good programs used two principles:
a) lookup tables, e.g for sinus values
b) looking at the requirements from a different perspective, which seemed to behave from the outside like expected, but was achieved in a unconventionel way
Long after that the geeks started to look at the underlying hardware. Before a) and b) did not happen it makes no sense to check wether LD A, #$00 is faster or EXOR A, A.
Underlying hardware is the point where you have to fiddel far mroe than just knowing assembler. How do you access a Joystick? Today with DirectX or some other device driver. In my days you wrote to a memory locations. That caused a condensator to be loaded. Then you started to read a second memory location in a loop. The
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Perl isn't faster than C, Perl is faster than _you_ writing C (no offsense to you personally, I mean you in the generic).
Engineering and the Ultimate
A number of years ago, while I was working for a Baby Bell, we were building a system, and integrating it with BEA's Tuxedo. One day a couple of the consultants came to me, to tell me that it was crashing, and they couldn't figure out why.
I pulled it up in the debugger (a Sun box), and stepped through the code...and, when I found it was crashing in Tuxedo, I did something the consultants (young guys) had no clue you could do...I stepi'd *into* the binary.
Now, I didn't know Sun assembly language, but that was irrelevant. I nexti'd and stepi'd my way through, and found the name of the function it was crashing in, which will *always* be there, even in a stripped binary, and where it was doing it in the function.
I could then call BEA (I was senior technical, and Rank Hath Its Privileges), and get info from their developers.
Turned out to be the environment, not a bug, but the point is, once in a while, *knowing* what how things work Down There will save your butt, and maybe even lead you to better code.
mark "and I pushed my kids to know what
happens under the hood of the car, too"
Randall Hyde regularly said that in his Assembly Language courses. Be aware that there are still occasions when Assembly is all you get, like embedded systems.
Possibly true of mechanics. Probably not true of painters. Quite a few great paintings are in serious trouble because the paints are falling off the canvas after only a 100 years.
Definitely not true of musicians who think in radically different terms from insturment builders. There seems to be a big hole in your analogy. Building an insturment is not analogous to writing in assembly language. A better analogy would be to say that building an insturment is analogous to building a CPU. Musicians think in abstractions such as beats and tones rather than in the terms of resonance, refraction, interference, and reflection that are central to insturment designers. Likewise, most programmers (even assembly programmers) think in terms of abstract bits moved or transformed from location to location rather than thinking in terms of resistance, capacitance, induction, and heat.
A better analogy would be to say that musicians learn a lot from practicing and composing etudes, compositions that focus on the relationship between musical theory and technique.
I was reading hex dumps and hand coding small assembler routines in high school (read: 24 years ago), and its been an invaluable skill over the years. I've written 'C' programs that call assembly routines to access OS functions that no routines existed for, understood how parameters got passed on the stack so when something got corrupted I could look at a hex dump and figure it out within minutes.
I took the TCP/IP software for an old minicomputer at my old job, licensed to the particular CPU, and figured out how to defeat the licensing so it'll run on any machine... all with no source, just by decoding/hacking the assembler and changing a few BNZ (branch Not Zero) to straight branches. I've played with building my own boards, and writing drivers for them.
From the standpoint of knowing how things work.. having the base knowledge of how the underlying hardware works, I can pretty much pick up any language on the fly.
I had a guy recently who I had to explain why:
status="green";
if (result1 >= 0) status="red";
if (result2 >= 0) status="red";
was better than:
if ((result1 >=0) && (result2 == 0)) status="red";
else if ((result1 == 0) && (result2 >= 0)) status="red";
else if ((result1 >= 0) && (result2 >= 0)) status="red";
else status="green";
no concept of the difference in 6 compares & 3 logical and's, vs two compares. Not that his way wouldn't work.. but *efficiency*. In a lot of ways, in my mind, mastery of assembly language can bring great insight into the *best* way to accomplish something.
I disagree wholeheartedly with the above, with the exception that readable code is important (more from a maintainability standpoint).
You talk about your python code feeling 'instantaious' (ignoring the spelling), which yes may very well be true on your one-user 2.4Ghz linux box at home with nobody else beating on it...
I manage java application servers used *worldwide* by perhaps 100K users/day. Our biggest server has probably 40 applications on it, any *one* of which, if ill-behaved, can affect the others. I've run into apps with poorly coded/planned sql queries that take 8 seconds to execute... throw that in a JVM taking 1000 hits/second with 100 threads.. you figure how long it takes for all the threads to block because they are waiting on DB requests, killing not only that one app but the other 5 in that same JVM. (hint, less than a second). It has *nothing* to do with the application code itself running slow (heck, the user hits return, and it generates that DB request in a fraction of a second), its just *poor design*.
As a sysadmin with 300K+ users using my apps, I've gotten bitten *many* times with new code being pushed to prod after "QA" testing that kills the production environment. I don't *like* being woken up at 2AM for an hour+ of poking around and then rolling back the code that was pushed that night. Exactly the same as what you are doing, the QA people test the application *by itself*, and then when it goes to production *I* have to deal with the effects of it running alongside 39 other apps.
My personal favorite OS is NetBSD. A year or so ago they made changes to the rc-script code, and after pushing to -current, a lot of people on older boxes (ie. vaxen, decstations) complained because it was so much slower. Yes, on your 2.4Ghz x86 box, your startup went from 0.5 seconds to 0.6 seconds... but on slower hardware it was far more dramatic.
People today are spoiled by "ah, it runs slow on my 2.4Ghz box, I'll just buy a 3.2 and it'll be fine". Thats fine if its just you on the box. Put 100 people on the box, and your 1-second runtime (that lets say could be optimized to 0.1 seconds if you wrote efficient code) equates to 100 second response for those 100 users. Optimize it to that 0.1 seconds, they get 10 second response. Which would *you* prefer?
I would have to execute the program 66 times to break even. If perl was 10x as slow as C, which isn't true.
You're right. According to Bagley's famous Great Shootout, perl is only twice as slow as C - for operations for which perl is optimised, such as accessing elements in associative arrays. For numerical operations, like matrix multiplication, the sort of thing where runtime optimisations have been shown to let Java perform as well as C, perl runs... 500 times slower than C.
If you want to champion high-level languages, pick a high-level language like Lisp or ML which can be compiled to native code. Ocaml programs regularly perform as well as C, despite being written in a language that's nearly as quick to program in as perl.
"Do you mean coordinating multiple distributed debuggers, or installing devenv in various places? Coordination can definitely be a pain, but there's no need to install devenv all over the place - just use ntsd."
.exe files, then you usually have to run 9 of them normally and one in the debugger. Still not that much of a problem, and you can run more than one process in a debugger if you don't mind it being a bit more complicated to synchronise.
To debug a piece of code on your development machine, just press F5 to start the program, run to a breakpoint, step through, etc.. And if you have a program that consists of 10
If you've got a feature that you can only test by having the code running on 4 machines talking to each other, then it becomes that much more difficult to use debuggers without really confusing yourself.
However, if a program crashes in a function, you can just put a MessageBox() after each block of code, compile it, and run it normally. The last messagebox displayed tells you where the crash is, and you can then narrow your search. It's very useful for finding crashes (which in Windows are normally null pointers).
For debugging networking-type code you can dump "events" (i.e. logging, which we probably should do even when not debugging) into a file. This is useful when there're lots of threads or processes communicating, and you want to know who sent what, and who received it. "Thread x on computer y received message z" and you can get all the messages in order. fprintf can also handle loads of different data types quite easily, so you can send strings to the file without having to allocate new memory to create a debug message in.
I still find the visual studio debugger quite good for looking at linked-lists and stuff, but it seems to get overwhelmed quite easily when you've got more than one program running at once.
Word!
The discussion that "knowing assembly makes you a better coder" pops up here at slashdot every once in a while.
I'd go out on a limb saying that a large part of the reason, for the popular belief that knowing assembly makes you a better coder, is that many people that have learned machine code are really dedicated coders and did it because it was fun. These people have a really good understanding of programming for many reasons, not only the fact that they know assembly.
Those are the people that have their voices heard on this subject here at Slashdot.
And those people are not necessarily the people I would trust to make a curriculum.
The Internet is full. Go Away!!!
When the FFT came out, a lot of effort went into cutting down the number of arithmetic operations -- eliminating "trivial" operations like multiply by 1, multiply by 0 and add, as well as they higher radix butterflies (radix 4, 8, 16). The simple radix 2 FFT given in many DSP texts was offered as a "teaching example", but "production" FFT programs were complex masses of FORTRAN code that attempted to identify all the optimizations.
In my own experience, the simple radix 2 FFT is best for the modern x86 where as you say x86 is just an API to a RISC core. The minute you start putting in the optimizations, you need additional loops, branches, and tests, which trip up the pipeline. Arithmetic ops are fast compared to extra loops, branches, and tests, so the old mainframe FFT subroutines were optimizing the wrong thin.
Yeh, silly me, forgetting about all those lisp applications I'm running. xemacs is probably the only one, I personally run, and it's slow, ugly and has more than a few annoying bugs (mainly with the UI). In fact it's so bad I keep looking for ways to migrate from it, but keep whimping out.
I actually like the parens, but I still don't write any real lisp apps. ... and have no intention of starting. Here's a free clue, I didn't learn python because I thought appending commas to the end of print statements was a great idea ... I learnt it because of pygtk.
When there's a free (as in perl and python) lisp language that's useful for doing things in ... those things will start to be done in lisp (I had hopes for rep, but that turned out not to be ... again).
ustr: Managed string API with ave. 44% overhead over strdup(), for 0-20B
What I generally do is overwrite new to place a 64 bytes marker before and after the memory block, which is then checked during delete, and will exit with a stack dump (and a hex dump of the block) if corrupted.
At exit I dump all blocks not deleted (to catch leaks), and I litter my code with asserts (which also do stack dumps) plus have a printf-kind of system, where the level of output can be toggled (often at run-time, if the application i am working on has a user interface (I have a debug-menu component which I just link on my application)).
Due to all the run-time checks, I generally catch mistakes the minute I make them -- I have debugged/resourced lots of other programs and have also programmed in assembler, so it's not a skill I lack, but I honestly never have a need to debug my own programs (except when the compiler produce the wrong instructions, but this is mainly just looking at the assembler output, rather than using the debugger).
My memory system doesn't watch for stack-corruption. This however never really happens, because I only place objects on the stack or const arrays -- if I need a mutable array I use std::vector
I also define _GLIBCXX_DEBUG, which turns on all sorts of sanity checks in the standard library.
BTW, it's not the case. Segfaulting was an easy clue, and what you needed to understand is how your program was allocating memory. People need to start managing their data or the language needs to start doing it for them.
Whoah, less caffeine for this man! ;-)
Seriously, I know, and knew back then, that the segfault indicated my process was overwriting someone else's memory. What I didn't know was whether it was a) a function in a library I was using, or b) my own code (which I seem to recall was something written recursively for added spice). If the latter, then I needed to know /where/ I was over-running an array, and peppering the source code with printf()s was no use (which was the original point of my post and its parent) as it made the program run "correctly".
--