News for hackers. Stuff that matters.
Re:Say Hello to X64 Assembly Part 3 by Havoc on Friday September 19, 2014 @06:18PM (#8342786)
You miss my point 100%. I know ASM code is technically superior.

However, the advances in tech have outpaced the advantages of ASM. Yes your code is 10x more efficient than mine, but I can throw 1000x as much processing power at this via cloud & a scripting languages.

Yes you've seen more "compiler-generated code" than I have but realistically...who is going to win this p!ssing contest? You writing ASM code or me scaling a scripting language across clouds? I bet I can deploy cloud processing power faster than you can

MOV AX,CS

MOV DS,AX

Also - I'm not in the cloud game - the above is a simple example/play the devils advocate.

Re:Say Hello to X64 Assembly Part 3 by dllthomas on Friday September 19, 2014 @06:31PM (#8342841)
It depends tremendously on context. For instance, it doesn't matter how many cloud resources you can throw at the problem if you need sufficiently small latencies.

Note that it's exceedingly rare that one should be writing an entire program in assembly. But knowing assembly allows you, as you bump up against performance constraints, to inspect what code is being generated and understand what's slowing things down, which can help guide you in adjusting the source so it will be faster, applying a better set of optimization options, hand-tweaking the generated assembly, or ultimately rewriting sections while having a reference implementation.

Re:Say Hello to X64 Assembly Part 3 by Havoc on Friday September 19, 2014 @06:46PM (#8342887)
>>if you need sufficiently small latencies.

I'll concede that you'll need ASM for core speed critical applications like stock exchanges...then again I conceded that point before we started debating...

>Note that it's exceedingly rare that one should be writing an entire program in assembly.

My mention of in-line ASM should have made that obvious that I'm not arguing for pure ASM.

>applying a better set of optimization options, hand-tweaking

You hand tweak your ASM, I deploy additional cloud clusters. We'll see which scales better (pro-tip: optimization is notoriously prone to diminishing returns).

Re:Say Hello to X64 Assembly Part 3 by dllthomas on Friday September 19, 2014 @06:57PM (#8342937)
">Note that it's exceedingly rare that one should be writing an entire program in assembly.

My mention of in-line ASM should have made that obvious that I'm not arguing for pure ASM."

That wasn't me arguing with you, it was an attempt to clarify my position on the matter in light of what else I said.

"You hand tweak your ASM, I deploy additional cloud clusters. We'll see which scales better"

That depends tremendously on, again, the context - including where one already stands on the various curves and on how parallel the problem is.

"(pro-tip: optimization is notoriously prone to diminishing returns)."

As is parallelism: http://en.wikipedia.org/wiki/Amdahl%27s_law

Re:Say Hello to X64 Assembly Part 3 by alecco on Friday September 19, 2014 @06:53PM (#8342917)
> but I can throw 1000x as much processing power at this via cloud & a scripting languages

This kind of stuff is why I stopped teaching and mentoring. It's like trying to convince creationists with facts.

Also, it's wide knowledge programmers spend the vast majority of time debugging. The other day I wasted an hour because a popular high level language doesn't warn users when comparing apples to oranges. I've spent on ocassion a lot of time chasing bugs in cloud services that make debugging close to impossible, too. There's no free lunch.