Assembly language programming vs Other programming languages

  • C/++/#
  • Thread starter ChrisVer
  • Start date
  • #51
86
25
I have never seen nor heard of an actual app ever being ported
I have been out of the industry for a while, but early in my career I was coding commercial data processing applications in 100% IBM assembler! Seems surreal to think of it these days. This software was 'ported' every time there was an upgrade to a new processor version even if nominally the same kind of machine.

I imagine the same would be true of assembler components in more recent systems, unless all such are hardware-specific drivers and such. So not 'porting' as in moving from one manufacturer to another maybe - but porting from one hardware version to another more recent one with different behaviour? Seems likely?
 
  • #52
"Porting" to upgraded hardware ... absolutely. I just never thought of it as "porting," in the commonly-accepted sense of the word, but really that's exactly what it is.

Ultimately everybody finds their niche and does the work they are most drawn to doing. Some like me are wretched outcasts, condescendingly viewed as idiots who just don't get it, but I'm happy with what I write and that's what matters most to me.
 
  • #53
Khashishi
Science Advisor
2,815
493
Assembly language was useful in the past to squeeze every last bit of performance out of a single processor, strictly sequential system. Nowadays, it isn't as relevant since performance programming has moved on to multicore systems with parallel computing and perhaps GPU computing. Assembly language is basically a list of sequential instructions for a CPU, but in modern systems, instruction handling isn't sequential or necessarily synchronous.
 
  • #54
1
0
Assemble language could have been by far the best, but then C-code came along, which is a higher level language that was soon adopted. Unfortunately, it is (in my opinion) not the best since it is not as efficient as it should be due to the way it is designed. Assembly code directly addresses all computer machine processes, of which there are many combinations. Many years ago, I designed an assembly code "typewriter" for a newly introduced microcomputer that had keys labeled with the all of the assemble code values. The intent was to make coding highly efficient. This would probably not be feasible for C-code. Unfortunately, the microcomputer company discontinued their microcomputer production line.
 
  • #55
FactChecker
Science Advisor
Gold Member
6,637
2,686
I have never seen nor heard of an actual app ever being ported. I'm sure it happens; I just don't see where. And I view the entire process as the ultimate in shoddy shortcuts and laziness. Just my personal opinion; we all have one.
Code reuse is desirable. I wouldn't consider it shoddy or lazy.
 
  • #56
18
30
I would argue that assembly language is *not* faster in anything other than perhaps the smallest microcontrollers.

I've got 30+ years behind the keyboard, man and boy. I've written large to very large chunks of software in assembly a dozen different CPUs 68xx, 68000, 68020, 68360, 68HC11, tms34020, 8086, 286, 386, 486,, 8052 etc.

I spent a decade programming from schematics, today I work on highly scalable and fault tolerant Java server side stuff.

The first fact of modern life is that counting cycles doesn't work with modern processors since they have pipelines. The compiler has a better view of instruction scheduling than you do, and no one can pretend that they can juggle that viewpoint on any non-trivial assembly language app. So unless you're writing for some simple-minded microcontroller, you can't claim it's faster until you run them side by side - in which case why write the assembler version in the first place? Profilers will tell you if it's needed.

The second fact of modern life is that scalability matters more than throwing raw CPU at it. So what if your Java code runs 1/4 as fast as assembly code? You write some readable code using an understandable pattern, throw some more cores at it and then you go make progress on the *purpose* you wrote the code for. Sitting around admiring all the shiny bits is not solving problems, it's a sort of engineering masturbation practiced by engineers who haven't grown up. (and I say that as a software engineer who can gold plate requirements and be more anal about code than most so I'm definitely including myself in that group)

The code is not the goal. Solving problems is the goal. The readability, scalability, maintainability of the code all matter far more than the performance, for a lot of reasons.

Biggest reason is this: You know where your code spends most of its time? No you don't. If you don't have profiler output from your application running in a production environment then all you're doing is guessing and I'd guesstimate a 95% chance that you're wrong. I've done it on many projects, even when were absolutely confident where the problem would be, we were wrong until at least the third pass through the profiling process.

Second biggest reason is that if your code is modular, based on standard patterns, and readable then you can identify the tiny percentage of your code that actually *might* be a performance bottleneck using readily available high level tools. You can't go the other direction, there aren't any tools to reverse engineer a buttload of spaghetti code hacked out in the name of "efficiency" and turn it into something readable/valuable. Also if the code is readable and based on standard patterns then you can at least understand it and consider whether you can solve the problem simply using scalability rather than resorting to the brute force/blunt axe of assembly language to cover up your design mistake or incorrect choice of algorithms.

In Agile you have the concept of "last responsible moment" You put off defining or doing work until as late as you can because the later in the process you are, the less likely you are to be affected by changes. To start out a project writing assembly code is the ultimate in "first irresponsible moment" because you've made the decision to invest maximum effort at a time when you've also got maximum uncertainty. If you get down to the last possible straw and assembly language is the only way to solve the problem then you've done your due diligence and it really has to be that way. Otherwise you're just fondling your pocket protector.

The only valid reason I know of for writing assembly code from the start is a manufacturing cost one. If you're going to make a million devices and you can save $1 on each one if you can use a cheaper microcontroller or CPU, you _might_ have an argument...though I'd still argue that the company's reputation for producing reliable products is a big implicit cost that often gets left out of that discussion.
 
  • #57
43
18
What was written in this thread about assembler code versus compiled code to my believe does not touch an equally critical argument for compiled programming. Modern processor architectures have multiple caches, do preprocess instructions, does pre-execute code based on assumption of the most probable branching of the code etcetera. To write assembler code that takes those issues into consideration is realistically seen very close to impossible for someone writing code in assembler. Compilers have so called "switches" that tell the compiler if the code it is going to generate is optimized for speed, for code density or a balance between those priorities. It then generates code that looks very different depending on the setting of such switches.

I did write the whole firmware for an NEC 7220 graphic controller to be used in a terminal and did write the assembler code for the MC6809. I guess none of you readers have ever heard about the NEC 7220 graphic controller that was very popular in the early 80's! Today, as it has been correctly stated in this thread neither memory nor CPU performance are really limiting factors and so today I use the language Python very much. This is an interpreted language which tends to be much slower than compiled code. tends to be is the term is used to express that languages are made of instructions and those are provided to a high extend as elements in libraries. The Python language, a scripting language can still be very efficient as the library elements can have been coded using C or C++, so that they are already present in machine language that can be executed directly from the processor or compiler. So a scripting language like Python can be just the tool to concatenate precompiled code of its library elements!
 
  • #58
phinds
Science Advisor
Insights Author
Gold Member
17,277
8,672
There's faster compiling languages than "C", we're talking about large factors faster.

https://brenocon.com/blog/2009/09/d...t-and-most-elegant-big-data-munging-language/

MAWK is one of the fastest languages out there and that makes a HUGE difference in transforming massive amounts of data where parallel computing becomes important.
As I understand it, that is NOT a general purpose language. It is "extremely specialized for processing delimited text files in a single pass"
 
  • #59
FactChecker
Science Advisor
Gold Member
6,637
2,686
I assume that modern assemblers have the same optimization options that higher level language compilers have.
 
  • #60
30
4
As I understand it, that is NOT a general purpose language. It is "extremely specialized for processing delimited text files in a single pass"
Well it does quite a bit more though, and is good for number crunching. Which is why I thought it interesting to mention here.
 
  • #61
phinds
Science Advisor
Insights Author
Gold Member
17,277
8,672
I assume that modern assemblers have the same optimization options that higher level language compilers have.
I don't think assemblers HAVE optimization. The assumption is that you mean exactly what you write.
 
  • Like
Likes QuantumQuest and FactChecker
  • #62
30
4
I don't think assemblers HAVE optimization. The assumption is that you mean exactly what you write.
A wizard is never buggy. He writes precisely what he means to.
 
  • #63
.Scott
Homework Helper
2,894
1,156
As has been mentioned earlier, assembler is used very sparingly. Even in situations where there is "no choice", the assembler is often isolated. For example, most CPU's provide a selection of "atomic" operations such as "compare and exchange". But rather than code the assembly, there are functions that usually place the required assembly inline with your code. In the Microsoft development environment, this is the "InterlockedCompareExchange()" function:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms683560(v=vs.85).aspx

Still, there are cases where a particular block of code needs to be executed as fast as possible - either because a very rapid response is needed or (more likely) that block of code is executed millions of times. In such cases, the first strategy is to devise an algorithm that is fast and allow certain optimizations, like placing functions inline to the main program and flatting loops. Many compilers will provide options for doing exactly this - and those optimizations can be applied specifically to the section of code that requires it.

But if all that is not enough, sometimes assembly code can be crafted that is substantially faster than compiler-generated assembly. The computer programmer can often device methods of arranging for the code to use different types of memory access cycles most efficiently and sometimes there are special functions provided by the CPU that can be used creatively to perform unexpected functions. In some cases, the result can be a 2 or 3 fold increase in speed. In a recent case, I was able to use machine instructions intended for digital signal processing to rapidly compute the median value for an integer array. But the situation was so specialized, it would make no sense to try to get a C++ compiler to mimic the technique.
 
  • #64
.Scott
Homework Helper
2,894
1,156
I don't think assemblers HAVE optimization. The assumption is that you mean exactly what you write.
That is correct. Assemblers don't optimize.
 
  • #65
FactChecker
Science Advisor
Gold Member
6,637
2,686
I don't think assemblers HAVE optimization. The assumption is that you mean exactly what you write.
Ok. I'll buy that.
 
  • #66
Khashishi
Science Advisor
2,815
493
Consider that in order to craft more optimized assembly than a compiler for a particular computer architecture, you need to be an expert at that particular architecture. And if you want it to run optimally on another computer, you'll have to find an expert to rewrite it for that computer. One of the best ways to improve the performance of a code is to run it on a faster system. If you hand craft it in assembly, you lose that option.

If you must get it to run as fast as possible, you should probably write it in FORTRAN or C.
 
  • Like
Likes FactChecker
  • #67
.Scott
Homework Helper
2,894
1,156
Consider that in order to craft more optimized assembly than a compiler for a particular computer architecture, you need to be an expert at that particular architecture. And if you want it to run optimally on another computer, you'll have to find an expert to rewrite it for that computer. One of the best ways to improve the performance of a code is to run it on a faster system. If you hand craft it in assembly, you lose that option.

If you must get it to run as fast as possible, you should probably write it in FORTRAN or C.
The case I cited above was an mass-produced embedded system with heat limitations. The issue isn't "as fast as possible" but simply "fast enough to keep up with a real time data stream". Moving to a faster processor would have caused too much heat and too much electric consumption - and the additional cost would have made the product much less competitive. As processors advance, we upgrade to the new technology, become experts in the new architecture, and create improved product. Sometimes that means assembly. But the total assembly is always way less than 1% of the code.
 
  • #68
rcgldr
Homework Helper
8,774
572
I would argue that assembly language is *not* faster in anything other than perhaps the smallest microcontrollers.

Take a look at post #21:

Assembly language programming vs Other programming languages

These are unusual cases, but they do exist.

The 500+ line CRC optimized for speed assembly code using pclmulqdq is something that a compiler isn't going to be able to duplicate, even with an intrinsic function for the pclmulqdq instruction. Intel created a document about this:

http://www.intel.com/content/dam/ww...ation-generic-polynomials-pclmulqdq-paper.pdf

The IBM mainframe assembly code is a combination of legacy code for file access methods (assembly macros). I'm not sure if the assembly modules using processor specific instructions for speed could be replaced by Cobol assuming it's optimizer takes advantage of those instructions, but who's going to replace fairly large libraries of working assembler code?
 
  • Like
Likes QuantumQuest
  • #69
35,394
7,271
Still, there are cases where a particular block of code needs to be executed as fast as possible - either because a very rapid response is needed or (more likely) that block of code is executed millions of times. In such cases, the first strategy is to devise an algorithm that is fast and allow certain optimizations, like placing functions inline to the main program and flatting loops. Many compilers will provide options for doing exactly this - and those optimizations can be applied specifically to the section of code that requires it.

But if all that is not enough, sometimes assembly code can be crafted that is substantially faster than compiler-generated assembly.
Indeed. I used to work in the MS Windows Division, and had access to the Windows code base. I remember seeing some video driver code with a few lines of inline assembly, possibly for lighting up pixels in display memory (that was about 10 or so years ago, so was somewhere in the XP or Vista timeframe).

A few years later I was working in the Office Division, and spotted some code for processing audio, that used some of the Intel SIMD instructions. I don't know if that code was actually shipped in any Office product, but I knew that someone had written it to take advantage of SIMD (single instruction, multiple data) technologies in the later Pentium and (I believe) AMD processors.

The point is that when you need to push a huge amount of data through at a high rate of speed, either for video display or speech recognition purposes, some well-crafted assembly can be very useful.
 
  • Like
Likes QuantumQuest
  • #70
jim mcnamara
Mentor
4,467
3,226
@phinds - we've had to clean up some bad posts and your answer is kind of dangling now. Sorry. Remember 'dangling participles' way back when? :smile:
 
  • #71
phinds
Science Advisor
Insights Author
Gold Member
17,277
8,672
@phinds - we've had to clean up some bad posts and your answer is kind of dangling now. Sorry. Remember 'dangling participles' way back when? :smile:
np. How could a grammar Nazi like me forget dangling participles? :smile:
 
  • #72
ChrisVer
Gold Member
3,381
462
So far the inputs tend to dissing assembly over the usage of several cores for speeding up the process...? So ASM seems to be losing the privilege it's so proud of?
Also one thing that seems unclear to me, is the speeding happening in the compilation time or for the program's runtime? In terms for an IDE during Building or during Running your code?
 
  • #73
FactChecker
Science Advisor
Gold Member
6,637
2,686
Also one thing that seems unclear to me, is the speeding happening in the compilation time or for the program's runtime? In terms for an IDE during Building or during Running your code?
I think practically all the posts are talking about execution speed, not compilation speed. There may be an exception or two.
 
  • #74
35,394
7,271
I think practically all the posts are talking about execution speed, not compilation speed.
I agree. The time it takes to compile is of little concern--the goal usually is to get the program to run faster.
 
  • #75
TMT
31
3
Hi guys,
I like to say that you can use either forks or spoons for eating.the question "which one is good for eating fork or spoon?" is an absurd question. fork is for some meal while spoon is good for some other. But keep in mind hand is also good for eating.
I mean, assembler is best for time and space mostly. But do you need this amount of speed or space?
The most crucial issue is algorithm. You can calculate time cost or space cost of algorithm. When you consider the bottleneck of your resources (CPU,memory,response time) you can reduce the cost with expense of others.
The memory used by program code is not too much important. Ok assembler will spend less memory for code (apparently) but consider the actual code running is not only program lines you wrote. You mostly utilise kernel (BIOS) codes (through interrupts or service calls)
When you use high level compilers same unseen things also happens. for example either DLL or ordinary library usage. How you manage them? how many routine packed together? There is no selective loading. Library modules load together at once. Then in linkage phase only requested codes wired with your code. Then, when you re organize the library modules you will observe great amount of shrinkage of module size. High level language try to provide a lot of stuff in their support libraries therefore resulting module sizes considerably greater than assembler.
if your resources is limited like as single chip processor with 1 kbyte ROM and 256 byte memory. every byte is important. Believe me you can challenge with this with wiser approach like explore logic and try to reuse code segments several times. But aware your code became real spaghetti. Maintenance of such a code become even impossible.
You can also speed up your code if you consider cache sizes and organize memory usage accordingly.
You can profile your high level programing codes to spot out bottleneck points. then write this portion with assembler. (but first check algorithm for that portion of code)
 
  • Like
Likes jim mcnamara

Related Threads on Assembly language programming vs Other programming languages

  • Last Post
Replies
18
Views
9K
  • Last Post
Replies
18
Views
5K
  • Last Post
Replies
19
Views
7K
  • Last Post
Replies
1
Views
839
Replies
4
Views
14K
Replies
11
Views
1K
  • Last Post
Replies
2
Views
912
  • Last Post
Replies
10
Views
5K
  • Last Post
Replies
16
Views
3K
  • Last Post
2
Replies
29
Views
2K
Top