Linked by Thom Holwerda on Sun 8th Jul 2012 22:54 UTC
General Development "In this tiny ebook I'm going to show you how to get started writing 6502 assembly language. [...] I think it's valuable to have an understanding of assembly language. Assembly language is the lowest level of abstraction in computers - the point at which the code is still readable. Assembly language translates directly to the bytes that are executed by your computer's processor. If you understand how it works, you've basically become a computer magician." More of this, please.
Thread beginning with comment 526122
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[4]: Comment by ilovebeer
by Alfman on Tue 10th Jul 2012 02:58 UTC in reply to "RE[3]: Comment by ilovebeer"
Alfman
Member since:
2011-01-28

DeepThought,

Yea, GCC often produces subpar code in my experience. Depending on how tight a loop needs to be, hand-crafted assembly can bring decent gains. Sometimes we can get away swapping in intrinsics, other times GCC just refuses to output good code.

ICC is supposed to be an excellent code optimiser though.

It's all relative though, computers have gotten so fast we're usually waiting on I/O anyway.

Reply Parent Score: 2

RE[5]: Comment by ilovebeer
by ilovebeer on Tue 10th Jul 2012 16:23 in reply to "RE[4]: Comment by ilovebeer"
ilovebeer Member since:
2011-08-08

Yea, GCC often produces subpar code in my experience. Depending on how tight a loop needs to be, hand-crafted assembly can bring decent gains. Sometimes we can get away swapping in intrinsics, other times GCC just refuses to output good code.

It needs to be said that coding in asm does not have automatic benefits of any kind. The quality of asm depends on the knowledge and capability of the person programming it. I've seen plenty of terrible asm. There _can be_ benefits to asm, but it isn't a given and shouldn't be overstated.

It's all relative though, computers have gotten so fast we're usually waiting on I/O anyway.

Yup.

Edited 2012-07-10 16:24 UTC

Reply Parent Score: 2

RE[5]: Comment by ilovebeer
by whartung on Tue 10th Jul 2012 18:24 in reply to "RE[4]: Comment by ilovebeer"
whartung Member since:
2005-07-06

t's all relative though, computers have gotten so fast we're usually waiting on memory anyway.


Fixed that for ya!

RAM is the new disk, bla bla...

If you ain't in cache, you ain't nothin.

Reply Parent Score: 2

RE[6]: Comment by ilovebeer
by Alfman on Tue 10th Jul 2012 21:41 in reply to "RE[5]: Comment by ilovebeer"
Alfman Member since:
2011-01-28

whartung,

"Fixed that for ya!"
"If you ain't in cache, you ain't nothin."

Actually, I may be using poor semantics, but I consider memory limited processes (whether from CPU or GPU) to be "IO" bound. After all, those requests have to be serialised over the system bus almost like any other IO. Obviously most programmers treat "memory" as though it's different from IO. While memory IO clearly plays a specific role for the CPU, from a databus-oriented point of view it's not all that special.

Semantics aside, it can be difficult to make SMP systems scale well if memory & IO are the real bottlenecks. I'd consider a CPU-bound process one that makes minimal use of the system bus, including system memory. I find many multithreaded advocates proposing to subdivide problems among tiny light weight threads, but very often they shift a problem from being CPU-bound (which is good for SMP) into one that is memory-bound which offsets the benefits of parallelism.

Even caching is problematic in that x86 processors must implement very strict cache coherency models, which severely limits SMP scalability.

Reply Parent Score: 2