Re:Assembly Language: Still Relevant Today
by blt on Friday November 06, 2015 @05:41PM
(#10522554)
Tangent: I wish more (any?) high-level languages were capable of expressing self-modifying code safely. A lot of values are variable at compile time but constant within a significant block of computation at runtime. If compilers were designed to emit self-modifying code, they could propagate constants through the block and replace register/register instructions with register/immediate instructions, freeing up registers for other variables. This is the promise of JIT compilers but in practice the popular jit-compiled languages have too many other performance issues to be popular for serious CPU-bound work. Plus the jitter has to do a lot of analysis at runtime. It would be cool if you could mark a block of C code with `#pragma jit`, making the compiler emit a binary that contains some compiler IR and a peephole optimizer to make the code as tight as possible given the conditions at runtime.
In fact, with the package system ASDF, you can recompile (incrementally) an entire package at runtime. This is a single blocking function call; something like:
(asdf:operate 'asdf:compile-op :my-package)
I have a web project where any request in dev mode triggers a system recompilation only if the git revision of the working tree is new.
That recompiles the system including MY-HANDLER, and right after RECOMPILE returns, the new version of MY-HANDLER from the working tree will be active.
The way Common Lisp lets me do that as a ten minute hack feels like living in the future... except of course it's pretty old technology!
Edit: I realize this is not really what you are talking about as "self-modifying code." Having full access to the compiler at runtime is a good first step for doing some of what you want, though. And with S-expressions, constructing and manipulating "ASTs" is ridiculously straightforward.
Re:Assembly Language: Still Relevant Today
by ChrisLomont on Friday November 06, 2015 @06:01PM
(#10522633)
C# (Microsoft stack, probably other stack, probably other .NET languages) lets you generate or input C# code at runtime, compile it, and run it through the jitter as desired. It's nearly trivial to do it. The Regex classes for example create code at runtime to do compiled regular expressions, but I think they do it with emitted IL instead of C# code directly.
Re:Assembly Language: Still Relevant Today
by dx211 on Friday November 06, 2015 @06:11PM
(#10522669)
.Net provides a couple of different ways to dynamically emit IL, but that's not quite the same as being able to emit your own native machine instructions, though. I think the challenge would be that you'd need to work out a calling convention between the jitted code and the emitted native code, at which point you might as well stick the native code in its own library function and compile or assemble it with a native tool.
Re:Assembly Language: Still Relevant Today
by ChrisLomont on Friday November 06, 2015 @08:45PM
(#10523253)
People have done this if you dig around. The basic idea is you can assemble arbitrary code into a byte array, then use an unsafe cast and use PInvoke to execute. The calling convention for many platforms has been reverse engineered, but I don't have a link handy. I've used it before to see if it works, and you can do it.
Re:Assembly Language: Still Relevant Today
by yaur on Friday November 06, 2015 @07:56PM
(#10523061)
Have you ever seen the jiter use SIMD? Having written some test code that was the simplest use case (multiply an array of floats by a float constant iirc) I have not. C# is a great language, but not for compute bound problems.
Re:Assembly Language: Still Relevant Today
by tbirdz on Friday November 06, 2015 @10:30PM
(#10523550)
Those are scalar instructions, not the SIMD instructions. With x86_64 the fpu stack operations are basically for legacy purposes only, and normal floating point operations are expected to be done with the SSE/AVX scalar instructions. SIMD instruction used the packed variants of the commands allowing you to multiple say 4 floats in a single instruction.
Re:Assembly Language: Still Relevant Today
by userbinator on Friday November 06, 2015 @11:16PM
(#10523683)
short sections of self-modifying code execute more slowly
Unless you're optimising for size, SMC'ing little pieces is definitely going to be slower. But e.g. in loops that do a few hundred iterations, saving a cycle or two by getting rid of some opaque predicates quickly adds up and the cache/pipeline-flushing overhead (few hundred cycles at most) becomes insignificant.
After all, as the parent comment says, a JIT is basically SMC'ing huge blocks of code, and it's definitely faster than the equivalent alternative of a bytecode interpreter.
Re:Assembly Language: Still Relevant Today
by wyager on Saturday November 07, 2015 @01:43AM
(#10523999)
Modern branch predictors handle opaque predicates (assuming you mean branches that don't change). Jump instructions in tight, repetitive loops on superscalar out-of-order processors are basically free.
Re:Assembly Language: Still Relevant Today
by exDM69 on Saturday November 07, 2015 @06:24AM
(#10524482)
Probably doesn't count as "high level" but you can embed the LLVM compiler backend to your project and compile and optimize code at runtime.
See the LLVM "Kaleidoscope" tutorials from the LLVM docs. They implement a simple toy compiler with a JIT-based REPL. Basically you use the LLVM framework to build a program and then run it through the compiler pipeline and get a callable function pointer to your newly compiled function(s), optimized for the CPU architecture you're running on.
Re:Assembly Language: Still Relevant Today
by easytiger on Saturday November 07, 2015 @04:18AM
(#10524255)
> It would be cool if you could mark a block of C code with `#pragma jit`, making the compiler emit a binary that contains some compiler IR and a peephole optimizer to make the code as tight as possible given the conditions at runtime.
Even if that remotely made any sense, which i don't think it does... c code compiles to the end target of all jits anyway, you just have some if statements or use pointers to other executable code that you swap around. Not only do you get the executable code as efficable as any jit, its constant with no jit cost. Its called c programming.
Re:Assembly Language: Still Relevant Today
by creshal on Saturday November 07, 2015 @06:21AM
(#10524476)
When you have variable types (say, you're deserializing foreign data, always fun), typical C code will end up having a huge switch() block do determine the type (expensive, e.g. due to branch prediction) and do something with it (trivial). Ahead-of-time compilation cannot optimize away the switch(), JIT can, by evaluating the data fed to the function at runtime.
What OP wants is a way to get the advantage of ahead-of-time compilation for the 99% of the code that benefit from it, and the advantages of JIT for the remaining 1% (or even less).
Re:Assembly Language: Still Relevant Today
by gdwatson on Friday November 06, 2015 @06:09PM
(#10522663)
Selectively using code generation to implement closures over immutable variables could get you part of the way there while allowing a lot of the work to be done at compile time and avoiding the need for a full JIT.
How much it would help performance in practice I couldn't say.
Re:Assembly Language: Still Relevant Today
by kazinator on Friday November 06, 2015 @06:53PM
(#10522839)
> If compilers were designed to emit self-modifying code
... then the high-level language isn't expressing self-modifying; the compiler is doing it to optimize the code while preserving the abstract meaning that is free of self-modifying.
Re:Assembly Language: Still Relevant Today
by gfody on Friday November 06, 2015 @05:58PM
(#10522617)
I can't think of any language that has this as a feature. But there are some nice libraries for assembling machine code at runtime - there was one I used called "softwire" that seems to have disappeared. I just found this one on github: https://github.com/kobalicek/asmjit
Re:Assembly Language: Still Relevant Today
by mgraczyk on Saturday November 07, 2015 @06:59AM
(#10524533)
I wrote up a small module to do this in C on x86 platforms. I called it a predicate replacer, but it can replace any integer constant. https://github.com/mgraczyk/fast_check_once
Re:Assembly Language: Still Relevant Today
by asveikau on Friday November 06, 2015 @11:54PM
(#10523777)
When I was at Microsoft, at least among several of the better developers, when debugging an issue, many would just ignore source code and enter a bunch of "u" (disassemble) commands into windbg. This is IMHO a great habit if you're writing C or C++. In many cases it ensures less distance between you and a bad pointer dereference. Your code, my code, source code, or none - doesn't matter. Just look at the faulting address and see what it expects.
From a certain vantage point, in these languages, if you aren't seeing assembly from time to time, you're not seeing reality.
Consequently, I kind of chuckle when I hear people say they can't debug optimized builds.
Re:Assembly Language: Still Relevant Today
by 13of40 on Friday November 06, 2015 @05:53PM
(#10522602)
Two or three years ago I was doing an informational interview, trying to move from a QA job to a developer job, and I mentioned to the guy that I used assembly code almost every day. He guffawed and said I was full of it, but it was true -- firing up a debugger and stepping through assembly might be pathological on the desktop these days, but when you're investigating a failure on a back-end datacenter machine that's running some interim build that's impossible to find matching symbols or source for, probably over a KVM...
Re:Assembly Language: Still Relevant Today
by swolchok on Friday November 06, 2015 @08:08PM
(#10523101)
I don't think it's unreasonable to differentiate between reading assembly produced by a compiler and handwriting assembly. I do the former several times a month and the latter almost never.
Re:Assembly Language: Still Relevant Today
by gaius on Saturday November 07, 2015 @07:01AM
(#10524539)
It's never reasonable to laugh at someone you're interviewing. Too many so-called engineers treat an interviewee just as a captive audience to brag about their own skills.
Re:Assembly Language: Still Relevant Today
by 13of40 on Friday November 06, 2015 @09:19PM
(#10523358)
Hell no. I was a dead man walking in that interview. When I was trying to transition from test to dev, half the people I interviewed with didn't even ask me technical questions. I had one interviewer show up half an hour late, spend the next 25 minutes trying to convince me to stay in test, then (literally) give me five minutes to whiteboard a linked-list problem in C++, and his feedback to the hiring manager was that I was lacking coding skills. I eventually got into a dev position, but it was it was an utterly medieval process. I wish I was kidding, but my take on the whole get-a-dev-job scene right now is that you have to be (a) young, (b) skinny, and (c) the same race as the hiring manager and interviewers (I shit you not). After that comes coding.
That project was using a CPU costing less than twenty cents to control the power of a consumer product. Code space mattered a lot, and doing the project entirely in a high-level language would have doubled the part cost. When you're talking quantities in the tens of millions, saving ten or twenty cents on the cost of goods is a Big Deal.
Re:Assembly Language: Still Relevant Today
by gfody on Friday November 06, 2015 @05:28PM
(#10522494)
No mention of graphics programming or signal processing? High level syntax just gets in the way when you're trying to pack six pixels into two registers just right. Assembly language is still pretty much the right tool for the job.
Re:Assembly Language: Still Relevant Today
by nickpsecurity on Friday November 06, 2015 @10:58PM
(#10523624)
There's a ton of people who don't need assembly. Including security engineers that work in C with tools like Astree or Frama-C. Then, tools such as CompCert compiler can handle the rest. ;)
Blackbox and reversing, though, certainly need or benefit from assembly. Depending one what one is analysing.
Re:Assembly Language: Still Relevant Today
by tikhonj on Saturday November 07, 2015 @12:12AM
(#10523825)
There's a big difference between "assembly is not relevant for anyone" and "assembly is not relevant for everyone". I suspect few people hold the former view and a bunch hold the latter, but shortened both sound the same.
Re:Assembly Language: Still Relevant Today
by noir_lord on Saturday November 07, 2015 @07:42AM
(#10524628)
This is pretty much it, the last time I touched assembly was to write some string routines for Delphi 5 as the included ones where horribly slow, that was 16 years ago.
Since these days I'm a web developer I'm at a level in the stack where using Assembly would be alien and frankly I doubt I could anyway without some serious study.
Re:Assembly Language: Still Relevant Today
by eva1984 on Saturday November 07, 2015 @03:04AM
(#10524128)
There are a lot of engineers out there work on higher abstractions. If the task is to write a map reduce or spark job, for sure, most of the time I don't think you need to know what happens with your application at assembly level.
Re:Assembly Language: Still Relevant Today
by exDM69 on Saturday November 07, 2015 @06:29AM
(#10524495)
This is pretty sad, but a lot of students tend to be only interested in whatever is applicable to the job market of present day.
However, even students do need assembly language when they take their computer architecture, operating systems and compilers classes. And some students will probably end up to do compilers or operating system work professionally at some point in their careers.
Assembly language is still a very valuable skill although a few people will ever write any code by hand. But reading assembly code as well as writing programs that emit assembly code will always stay relevant.
Re:Assembly Language: Still Relevant Today
by Everlag on Saturday November 07, 2015 @01:37AM
(#10523990)
To be fair, students are mostly learning MIPS32. It's a 'language' great for teaching concepts while preserving the students' sanity. The fact that I have to run an emulator of an effectively dead-for-consumer use architecture to write labs hurts student satisfaction. You can't even be cheeky and use interesting, assembly dominated elements like SIMD.
The true masochists continue to x86 in the higher level courses.
Re:Assembly Language: Still Relevant Today
by eru on Saturday November 07, 2015 @08:05AM
(#10524671)
Is the going rate for Haskell in finance especially high?
I used to work with Haskell in finance, but as an employee not contractor. Money was OK, but not higher than for any other language as far as I can tell.
(I wouldn't be surprised if going rates for Cobol and Fortran were higher than for any sane language.)
Re:Assembly Language: Still Relevant Today
by marssaxman on Friday November 06, 2015 @08:56PM
(#10523294)
Huh. Too bad it's finance. Is there anyone in a non-parasitic industry still paying that kind of money for assembly coding? Maybe I should get back into it. I always loved the low-level world, anyway.
Re:Assembly Language: Still Relevant Today
by pmjordan on Saturday November 07, 2015 @06:02AM
(#10524437)
I can't comment on £1500 specifically but there's plenty of (IMO) well-paying demand for low-level dev work out there in the tech industry in general. (Whether you consider the tech industry parasitic is of course another matter entirely…; I've never worked in finance and I do alright.) I don't know about predominantly writing assembly code, but that probably exists, too (SIMD…). Personally, I read a lot more (dis-)assembly than I write.
General advice for deeply technical consulting: you need to have a lot of deep practical experience in a few specific areas and you'll generally need to hit the ground running no matter what project you're dropped into and rapidly start generating corresponding value for the client. And expect to be continuously fighting off offers of permanent employment once you start picking up work.
Re:Assembly Language: Still Relevant Today
by sonthonax on Saturday November 07, 2015 @12:15AM
(#10523840)
I have difficulty believing that beyond the rare exception, those who earn over £1500 a day are nothing more than rent seekers who's staying power is more political than based on work and skill.
Re:Assembly Language: Still Relevant Today
by nickpsecurity on Sunday November 08, 2015 @05:11PM
(#10530206)
Exactly. It certainly takes strength in the skill of politics. While some are naturals, it's an art and science that's anything but simple. The people on top were often groomed for it by experts (parents or whatever) over literally decades. They also get lots of practice during that time.
That's why I tell people who want to be rich or powerful to master people skills, maintain right image, go to right schools, get the right connections, and deal/negotiate their way to top manager by manger, boardroom by boardroom.
Re:Assembly Language: Still Relevant Today
by bonobo3000 on Saturday November 07, 2015 @12:15AM
(#10523839)
Finance is the "parasitic" industry that powers every big VC and every tech IPO - the reason that founders can pay programmers as much as they do these days.
Re:Assembly Language: Still Relevant Today
by cma on Saturday November 07, 2015 @01:29AM
(#10523976)
I can see the guy in Saudi Arabia saying this now: royalty is a "parasitic" class that powers every big oil deal -- the reason that businesses can pay oil workers as much as they do these days.
(I'm not criticizing your conclusion, just your argument)
Re:Assembly Language: Still Relevant Today
by mettamage on Friday November 06, 2015 @09:50PM
(#10523452)
I'm a bit surprised by the title of the article. The content was a fun and interesting read. When I read the title I thought to myself: "of course assembly is still relevant!"
Which group of people or school of thought would say that assembly isn't relevant? I'm genuinely curious.
Re:Assembly Language: Still Relevant Today
by nickpsecurity on Friday November 06, 2015 @10:56PM
(#10523616)
"writing text editors in javascript"
Just 5-10 years ago, that might have been considered a joke. Now I wonder if you're referring to a specific project. And if it's already deployed as a Droplet. ;)
Re:Assembly Language: Still Relevant Today
by nickpsecurity on Saturday November 07, 2015 @01:09PM
(#10525613)
Oh I've seen plenty of JS stuff. That was the most incredible one I knew of. But a friggin text editor given all platforms have several good ones? And with less bugs & MB than a browser. I mean, come on...
Re:Assembly Language: Still Relevant Today
by nickpsecurity on Saturday November 07, 2015 @01:12PM
(#10525623)
Nice little pissing contest they have going on haha. I wonder if the rewrite (a) resulted in eliminating inefficiencies in MS Office code to make up for JS overhead or (b) led them to advise old strategy of telling users to buy better hardware.
http://clhs.lisp.se/Body/f_cmp.htm
In fact, with the package system ASDF, you can recompile (incrementally) an entire package at runtime. This is a single blocking function call; something like:
(asdf:operate 'asdf:compile-op :my-package)
I have a web project where any request in dev mode triggers a system recompilation only if the git revision of the working tree is new.
(my-handler :did-recompile (when (revision-is-new) (recompile) t))
That recompiles the system including MY-HANDLER, and right after RECOMPILE returns, the new version of MY-HANDLER from the working tree will be active.
The way Common Lisp lets me do that as a ten minute hack feels like living in the future... except of course it's pretty old technology!
Edit: I realize this is not really what you are talking about as "self-modifying code." Having full access to the compiler at runtime is a good first step for doing some of what you want, though. And with S-expressions, constructing and manipulating "ASTs" is ridiculously straightforward.
All the pieces are there.
Of course the JITer will not perform the same level of optimizations as the fullblown code generator, but then you can just call that if you like.
The new JIT engine does support SIMD [1]. And C# can generate SIMD code using various libraries (I think MS has one, and I know Mono does).
And various people have shown how to do fullblown x86 assembly code generation and execution from within C#, but it's fragile.
[1] http://blogs.msdn.com/b/dotnet/archive/2014/04/07/the-jit-fi...
00007ff8`80a804a9 488d549010 lea rdx,[rax+rdx*4+10h]
00007ff8`80a804ae c4e17a1002 vmovss xmm0,dword ptr [rdx]
00007ff8`80a804b3 c4e17a590524000000 vmulss xmm0,xmm0,dword ptr [00007ff8`80a804e0]
00007ff8`80a804bc c4e17a1102 vmovss dword ptr [rdx],xmm0
This is in VS 2013, compiled with DEBUG off, prefer x86 off, and 'any cpu' as the target.
- Use the new RyuJIT
- Make use of 64 bits CPU
- Use the vector and matrix classes from System.Numerics
Unless you're optimising for size, SMC'ing little pieces is definitely going to be slower. But e.g. in loops that do a few hundred iterations, saving a cycle or two by getting rid of some opaque predicates quickly adds up and the cache/pipeline-flushing overhead (few hundred cycles at most) becomes insignificant.
After all, as the parent comment says, a JIT is basically SMC'ing huge blocks of code, and it's definitely faster than the equivalent alternative of a bytecode interpreter.
See the LLVM "Kaleidoscope" tutorials from the LLVM docs. They implement a simple toy compiler with a JIT-based REPL. Basically you use the LLVM framework to build a program and then run it through the compiler pipeline and get a callable function pointer to your newly compiled function(s), optimized for the CPU architecture you're running on.
Even if that remotely made any sense, which i don't think it does... c code compiles to the end target of all jits anyway, you just have some if statements or use pointers to other executable code that you swap around. Not only do you get the executable code as efficable as any jit, its constant with no jit cost. Its called c programming.
What OP wants is a way to get the advantage of ahead-of-time compilation for the 99% of the code that benefit from it, and the advantages of JIT for the remaining 1% (or even less).
However, I'm not sure how feasible that would be.
How much it would help performance in practice I couldn't say.
... then the high-level language isn't expressing self-modifying; the compiler is doing it to optimize the code while preserving the abstract meaning that is free of self-modifying.
From a certain vantage point, in these languages, if you aren't seeing assembly from time to time, you're not seeing reality.
Consequently, I kind of chuckle when I hear people say they can't debug optimized builds.
http://www.dadhacker.com/blog/?p=1911
That project was using a CPU costing less than twenty cents to control the power of a consumer product. Code space mattered a lot, and doing the project entirely in a high-level language would have doubled the part cost. When you're talking quantities in the tens of millions, saving ten or twenty cents on the cost of goods is a Big Deal.
The article is begging the question. I'm unaware of anyone who thinks assembly is not relevant.
Blackbox and reversing, though, certainly need or benefit from assembly. Depending one what one is analysing.
Since these days I'm a web developer I'm at a level in the stack where using Assembly would be alien and frankly I doubt I could anyway without some serious study.
They call javascript the "assembly" of the web, yeah certain subsets of programmers are interesting in their beliefs.
However, even students do need assembly language when they take their computer architecture, operating systems and compilers classes. And some students will probably end up to do compilers or operating system work professionally at some point in their careers.
Assembly language is still a very valuable skill although a few people will ever write any code by hand. But reading assembly code as well as writing programs that emit assembly code will always stay relevant.
The true masochists continue to x86 in the higher level courses.
That is higher than the going rate for Haskell in finance afaik.
So yes, still relevant.
I used to work with Haskell in finance, but as an employee not contractor. Money was OK, but not higher than for any other language as far as I can tell.
(I wouldn't be surprised if going rates for Cobol and Fortran were higher than for any sane language.)
General advice for deeply technical consulting: you need to have a lot of deep practical experience in a few specific areas and you'll generally need to hit the ground running no matter what project you're dropped into and rapidly start generating corresponding value for the client. And expect to be continuously fighting off offers of permanent employment once you start picking up work.
That's why I tell people who want to be rich or powerful to master people skills, maintain right image, go to right schools, get the right connections, and deal/negotiate their way to top manager by manger, boardroom by boardroom.
(I'm not criticizing your conclusion, just your argument)
Oh grow up
For others?
Which group of people or school of thought would say that assembly isn't relevant? I'm genuinely curious.
Just 5-10 years ago, that might have been considered a joke. Now I wonder if you're referring to a specific project. And if it's already deployed as a Droplet. ;)
Text editors are pretty tame beasts by comparison.
Which was it?