If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Rate Thread | Display Modes |
#31
|
|||
|
|||
C is not a low level language
Wolf K writes:
[...] I think human-created assembler is becoming rare. However, I have the impression that robotics requires machine-coded assembler, translated from whatever human-readable language was used to program the machine. That's true of compiled languages in general, and is not specific to robotics. Most compiled languages are translated to assembly language (or directly to machine language, depending on how the compiler is designed). (Some, such as Java, are compiled to some kind of byte code which is then interpreted, but Java can also be compiled to assembly or machine code.) [...] [Followups to comp.programming, which is the only one of the cross-posted newsgroups that seems appropriate.] -- Keith Thompson (The_Other_Keith) http://www.ghoti.net/~kst Will write code for food. void Void(void) { Void(); } /* The recursive call of the void */ |
Ads |
#32
|
|||
|
|||
C is not a low level language
On 25/02/2019 15:38, David Brown wrote:
There are almost no programming fields that require hand-written assembly these days. Even if you are writing a compiler, or low-level libraries for a compiler, you are unlikely to need more than small sections or snippets of assembly. There are still occasions where assembly will give you noticeably more efficient results than a high-level language - but very, very few where the difference is big enough to warrant using assembly. Generally, if you think assembly is the best choice then you have picked an inappropriate processor, inappropriate tools, or an inappropriate programmer. The sorts of arguments can be made against using C or C++. With 90% of the code of an application, probably it doesn't matter how efficient a language or compiler is, because the bottlenecks are in the 10%. |
#33
|
|||
|
|||
C is not a low level language
In article , Bart wrote:
There are almost no programming fields that require hand-written assembly these days. Even if you are writing a compiler, or low-level libraries for a compiler, you are unlikely to need more than small sections or snippets of assembly. There are still occasions where assembly will give you noticeably more efficient results than a high-level language - but very, very few where the difference is big enough to warrant using assembly. Generally, if you think assembly is the best choice then you have picked an inappropriate processor, inappropriate tools, or an inappropriate programmer. The sorts of arguments can be made against using C or C++. With 90% of the code of an application, probably it doesn't matter how efficient a language or compiler is, because the bottlenecks are in the 10%. more like 1% |
#34
|
|||
|
|||
C is not a low level language
On Mon, 25 Feb 2019 12:17:51 -0500, nospam
wrote: In article , NY wrote: When I was at university, doing electronic engineering, in the early 1980s, we did a bit of assembler programming, in 6809. Everyone was very frustrated at the choice of CPU because those who had their own computer had either a CP/M-based (Z80) or Commodore Pet (6502); no-one had a computer that used a 6809 that they could practice on out of hours. Of course, a few years later, 8086 and its successors (386, 486 etc) would have been fairly universal ;-) Nowadays they'd probably also teach RISC (eg SPARC and ARM) processors. their frustration was unfamiliarity and inability to learn new things. the 6809 was a *very* good processor, along with its successor, the 68000 series,*far* easier to write code than the z80 and x86. My experiences ran in the other direction. I cut teeth on the 6809, and when I was later exposed to the 80286 it was an abrupt shift in perspective. I never played with the 6502 or Z80, it would have irritated me at the time, but from this distance I think it would have been valuable experience. it working. I forget the actual timings, but I know that the Z80 routine was several orders of magnitude faster than the same algorithm in interpreted BASIC and several times faster than a compiled Pascal program with the same algorithm. that just means the compiler wasn't any good. No surprise with BASIC, it was always a dog in those days. Didn't some of the Pascal systems utilize a kind of byte code running in a virtual executive? That might do it. I never noticed Pascal being especially slower than equivalent C, but I never did anything very demanding with it, and I might not have been using a p-code based system anyway. Borland used to be a hell of a compiler shop. |
#35
|
|||
|
|||
C is not a low level language
On Mon, 25 Feb 2019 13:05:32 -0500, nospam
wrote: In article , NY wrote: but I know that the Z80 routine was several orders of magnitude faster than the same algorithm in interpreted BASIC and several times faster than a compiled Pascal program with the same algorithm. that just means the compiler wasn't any good. yep, and it's *really* hard to beat a modern compiler The compiler in question was Turbo Pascal of mid- to late-1980s vintage, running on a Z80 under CP/M 3. I'm not sure how efficient that was. that's not a modern compiler nor a modern processor either. As you say, modern compilers may well be more efficient - but they may also bloat the code with code that was never actually called but was compiled in nevertheless ;-) they don't, but even if that were true, code that is not called can't slow anything down. I should have tried to code a more efficient sort algorithm than bubble sort, to see how much improvement there was, but bubble is simple to remember (*) and to code, and I was doing it as a programming exercise rather than with a real-life application that needed the fastest sort available. (*) I can remember it without needing to look it up every time, and I can visualise exactly what it's doing, whereas shell sorts start to make my brain hurt working out what they are doing ;-) bubble sort is very easy to write, it's just not fast. Insertion sort is even easier to write. And it's usually twice as fast as bubble sort. |
#36
|
|||
|
|||
C is not a low level language
On 25/02/2019 18:49, J. P. Gilliver (John) wrote:
In message , Wolf K writes: On 2019-02-25 10:38, David Brown wrote: [...] There are almost no programming fields that require hand-written assembly these days.Â* Even if you are writing a compiler, or low-level libraries for a compiler, you are unlikely to need more than small sections or snippets of assembly.Â* There are still occasions where assembly will give you noticeably more efficient results than a high-level language - but very, very few where the difference is big enough to warrant using assembly.Â* Generally, if you think assembly is the best choice then you have picked an inappropriate processor, inappropriate tools, or an inappropriate programmer. Â*I think it is good for programmers to have some experience of assembly, and to have understanding of it - it helps give a better appreciation of how things work underneath, and can lead to the programmer writing better high-level code (especially on smaller systems).Â* But that is different from actually writing assembly for real work. [...] Thanks for this, +1. I'd agree that - IMO anyway - it helps for programmers to have had some _experience_ of assembler, to - as you say - have a better appreciation of how things work underneath, and write better code. But there are now probably few places where the extra efficiency assembler can yield justifies the extra cost of _using_ it. (_Knowing_ about it I still think should be part of any training course that involves programming, though.) There are times when using some assembly code can help. It is almost always sufficient to use inline assembly mixed with high-level code (typically C or C++, possibly other compiled languages). You get the benefits of assembly mainly when the processor has features that are not easy to express in the main language - say, SIMD instructions. Combining inline assembly with high-level language (using a compiler that can support this well) is likely to give you more optimal code. Yes, I still think assembler can produce more efficient code - but for all but the simplest systems, coding it requires more brain power (which costs money) than is justifiable in most cases: and _checking_ it is a really stressful activity: it requires phenomenal concentration. For any sizeable project, you need to have more than one coder working on it - and the effort they have to put into translating the inputs and outputs into a standard format to talk to each other arguably defeats the efficiency gains. If they _don't_ use standard interfaces, the _maintainability_ suffers, as any maintainer has to learn the details of the bespoke interfaces. Yes. Obviously anything that /could/ be written in a high level language could also be written in assembly with at least as high efficiency on a particular target - and there are assembly tricks that can't be practically done with compilers. But while that is the theory, practice is very different. If you add some reasonable conditions - the code should be legible, maintainable, and portable within the ISA (e.g., it should work for any x86-64 cpu), then it is a very different matter. The high level code will almost always run faster than assembly written under these constraints. This applies also for FPGA type work, too (programming in e. g. VHDL or High-C). Yes. _Ideally_, the compiler - or optimiser - will remove unnecessary format translation stages. The two places where ultimate efficiency matter are for very long-life, low-supply situations, such as space probes or similar situations, and _very_ mass-produced and cheap devices. And even for both of those, there are plenty of examples of where something went wrong - Ariane V, that hole in MoDem/router devices from a year or two ago - though I don't know in those particular cases whether it was in assembler or a medium-level or high-level language where the problem occurred. |
#37
|
|||
|
|||
C is not a low level language
On 25/02/2019 18:17, nospam wrote:
In article , David Brown wrote: There are almost no programming fields that require hand-written assembly these days. Even if you are writing a compiler, or low-level libraries for a compiler, you are unlikely to need more than small sections or snippets of assembly. There are still occasions where assembly will give you noticeably more efficient results than a high-level language - but very, very few where the difference is big enough to warrant using assembly. Generally, if you think assembly is the best choice then you have picked an inappropriate processor, inappropriate tools, or an inappropriate programmer. exactly I think it is good for programmers to have some experience of assembly, and to have understanding of it - it helps give a better appreciation of how things work underneath, and can lead to the programmer writing better high-level code (especially on smaller systems). But that is different from actually writing assembly for real work. what matters the most are good algorithms, and knowing assembly does not help with that. That is often the case - but certainly not always. Good algorithms are important when "n" is big - but "n" is usually small. For a small enough size, bubblesort will beat heapsort. Good algorithms are not to be underestimated - but not overestimated either. And knowing assembly can give better algorithm implementations, simply because the programmer is more aware of the underlying hardware. It can help when you are trying to decide if you should be fiddling with objects, or pointers to objects, for example. |
#38
|
|||
|
|||
C is not a low level language
On 25/02/2019 23:33, Bart wrote:
On 25/02/2019 15:38, David Brown wrote: There are almost no programming fields that require hand-written assembly these days.Â* Even if you are writing a compiler, or low-level libraries for a compiler, you are unlikely to need more than small sections or snippets of assembly.Â* There are still occasions where assembly will give you noticeably more efficient results than a high-level language - but very, very few where the difference is big enough to warrant using assembly.Â* Generally, if you think assembly is the best choice then you have picked an inappropriate processor, inappropriate tools, or an inappropriate programmer. The sorts of arguments can be made against using C or C++. With 90% of the code of an application, probably it doesn't matter how efficient a language or compiler is, because the bottlenecks are in the 10%. Agreed. For a lot of programming, C is a poor choice of language (better than assembly, but still not good). C++ is a different matter - it spans low-level and high-level coding, and thus covers a far wider range of applications. But often a high-level language such as Python makes it much easier to write safe and clear code - and correctness beats run-time efficiency every time. |
#39
|
|||
|
|||
C is not a low level language
Robert Wessel writes:
bubble sort is very easy to write, it's just not fast. Insertion sort is even easier to write. And it's usually twice as fast as bubble sort. Bubble sort is the fastest, on a vector already sorted. It's O(n) with the best constants in this best case. -- __Pascal J. Bourguignon__ http://www.informatimago.com |
#40
|
|||
|
|||
C is not a low level language
On 25/02/2019 20:40, nospam wrote:
In article , Wouter Verhelst wrote: what matters the most are good algorithms, and knowing assembly does not help with that. What helps with that is understanding of how a computer works; understanding the difference between registers and memory locations, and understanding how a processor performs calculations and stores the results of those calculations. that does not matter. Yes it does. what matters is using the best algorithm for a given task. The best algorithm to break RSA requires a quantum computer. It's a very good algorithm, but on a standard computer it will not perform very well. The same is true for very many other algorithms: they may be very good, but will not perform well on real hardware. If you need to design an algorithm, it helps if you understand how the hardware works. a ****ty algorithm written in highly optimized assembly and using only registers is still a ****ty algorithm. I didn't say that. I said it helps to design good algorithms if you understand how the hardware works. Once you do, it does not matter whether you write that algorithm in C, Pascal, or Assembler. It's impossible to write assembly language without at least a basic understanding of how computers work, and it's definitely the case that writing assembly language helps you learn that a bit more; so in that respect it most certainly does help with writing good algorithms. with *very* rare exception, there's no longer a need to write assembly language anymore. That's pretty extremely far besides the point I was trying to make... |
#41
|
|||
|
|||
C is not a low level language
On 25/02/2019 20:38, Scott Lurndal wrote:
Again, it would need to be included in a code path that _could_ have been executed (e.g. on a conditional branch) for speculative execution to have caused any issues. That is true; but the code in question was behind a "this really shouldn't happen, but in case it does, ..." type of test. Speculative execution will still pick that up, and it caused the program in question to crash. The unlikely condition abstract enough that the compiler could not optimize it out, let alone the speculative execution in the processor, but beyond that it was never going to be actually executed. Except speculatively, which caused the crash. I should have been clearer about that. Speculative execution doesn't just pick up random bits of the instruction stream and start executing them. Sure. |
#42
|
|||
|
|||
C is not a low level language
On 25/02/2019 20:40, nospam wrote:
In article , Wouter Verhelst wrote: code that is not called can't slow anything down. That's actually not true. it is true. what matters is the code that *is* called. You're saying that the code can't slow thing down if it's not called. That's a fairly absolute statement; I just showed you a counter-example, and so did Scott. So your absolute statement is just *wrong*. Code that is not called but is compiled in will use up space in a memory page. If that means the code segment of the program grows beyond a page boundary, that may then mean an extra page fault will need to be handled when part of the program is swapped out, which would otherwise not be necessary. that's more theoretical than anything real. It does happen though, and the more "not called" code you add to a program the larger the chances of this happening. Also, it pollutes the processor cache, as Scott pointed out, which will be more likely. nearly everything is i/o bound, and then there are all the other processes... It's precisely the other processes which will cause (part of) your program to get (partially) paged out if it is huge, which will cause your slowdowns. |
#43
|
|||
|
|||
C is not a low level language
In article , David Brown
wrote: There are almost no programming fields that require hand-written assembly these days. Even if you are writing a compiler, or low-level libraries for a compiler, you are unlikely to need more than small sections or snippets of assembly. There are still occasions where assembly will give you noticeably more efficient results than a high-level language - but very, very few where the difference is big enough to warrant using assembly. Generally, if you think assembly is the best choice then you have picked an inappropriate processor, inappropriate tools, or an inappropriate programmer. exactly I think it is good for programmers to have some experience of assembly, and to have understanding of it - it helps give a better appreciation of how things work underneath, and can lead to the programmer writing better high-level code (especially on smaller systems). But that is different from actually writing assembly for real work. what matters the most are good algorithms, and knowing assembly does not help with that. That is often the case - but certainly not always. Good algorithms are important when "n" is big - but "n" is usually small. For a small enough size, bubblesort will beat heapsort. Good algorithms are not to be underestimated - but not overestimated either. And knowing assembly can give better algorithm implementations, simply because the programmer is more aware of the underlying hardware. It can help when you are trying to decide if you should be fiddling with objects, or pointers to objects, for example. false. |
#44
|
|||
|
|||
C is not a low level language
In article , Wouter Verhelst
wrote: what matters the most are good algorithms, and knowing assembly does not help with that. What helps with that is understanding of how a computer works; understanding the difference between registers and memory locations, and understanding how a processor performs calculations and stores the results of those calculations. that does not matter. Yes it does. no, it does not. what matters is using the best algorithm for a given task. The best algorithm to break RSA requires a quantum computer. It's a very good algorithm, but on a standard computer it will not perform very well. that's entirely different. The same is true for very many other algorithms: they may be very good, but will not perform well on real hardware. nonsense. If you need to design an algorithm, it helps if you understand how the hardware works. nope. the hardware is irrelevant. a good algorithm will still be good if the hardware changes. a ****ty algorithm makes assumptions about the hardware, and when it does change, does not work well, or at all. a ****ty algorithm written in highly optimized assembly and using only registers is still a ****ty algorithm. I didn't say that. I said it helps to design good algorithms if you understand how the hardware works. Once you do, it does not matter whether you write that algorithm in C, Pascal, or Assembler. it makes little difference how the hardware works. It's impossible to write assembly language without at least a basic understanding of how computers work, and it's definitely the case that writing assembly language helps you learn that a bit more; so in that respect it most certainly does help with writing good algorithms. with *very* rare exception, there's no longer a need to write assembly language anymore. That's pretty extremely far besides the point I was trying to make... it's correct. modern compilers generate code far better than any human can do in almost every case. |
#45
|
|||
|
|||
C is not a low level language
On 26/02/2019 15:02, nospam wrote:
In article , David Brown wrote: There are almost no programming fields that require hand-written assembly these days. Even if you are writing a compiler, or low-level libraries for a compiler, you are unlikely to need more than small sections or snippets of assembly. There are still occasions where assembly will give you noticeably more efficient results than a high-level language - but very, very few where the difference is big enough to warrant using assembly. Generally, if you think assembly is the best choice then you have picked an inappropriate processor, inappropriate tools, or an inappropriate programmer. exactly I think it is good for programmers to have some experience of assembly, and to have understanding of it - it helps give a better appreciation of how things work underneath, and can lead to the programmer writing better high-level code (especially on smaller systems). But that is different from actually writing assembly for real work. what matters the most are good algorithms, and knowing assembly does not help with that. That is often the case - but certainly not always. Good algorithms are important when "n" is big - but "n" is usually small. For a small enough size, bubblesort will beat heapsort. Good algorithms are not to be underestimated - but not overestimated either. And knowing assembly can give better algorithm implementations, simply because the programmer is more aware of the underlying hardware. It can help when you are trying to decide if you should be fiddling with objects, or pointers to objects, for example. false. Now that was a well-written argument. Well done! (plonk) |
Thread Tools | |
Display Modes | Rate This Thread |
|
|