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 | Display Modes |
#61
|
|||
|
|||
Linux founder tells Intel to stop inventing 'magic instructions' and 'start fixing real problems'
In article , Brian Gregory
wrote: I remember - I _think_ it was in the last decade, but it might have been more - being startled when I spoke to a young computing graduate, to find he'd never done any assembler. At that time, after my initial double-take, I thought to myself: the field is big enough, that there'll be plenty of room for him, and in practice he'll probably never have any trouble finding interesting and well-paid employment. there is no need for assembler anymore, except in very rare circumstances. On PCs maybe. on just about everything. it's *really* difficult for a human to write assembler that's better than what a modern compiler can produce, plus doing so would take a *lot* longer. I bet some embedded stuff for ultra cheap mass market stuff is still done in assember, or something only very slightly higher level. you'd lose that bet. |
#62
|
|||
|
|||
Linux founder tells Intel to stop inventing 'magic instructions' and 'start fixing real problems'
In article , J. P. Gilliver (John)
wrote: I remember - I _think_ it was in the last decade, but it might have been more - being startled when I spoke to a young computing graduate, to find he'd never done any assembler. At that time, after my initial double-take, I thought to myself: the field is big enough, that there'll be plenty of room for him, and in practice he'll probably never have any trouble finding interesting and well-paid employment. there is no need for assembler anymore, except in very rare circumstances. On PCs maybe. I bet some embedded stuff for ultra cheap mass market stuff is still done in assember, or something only very slightly higher level. Yes. Define "need". Compact code is noticeably more efficient - so runs faster. Yes, for a lot of things, the returns don't justify the effort - for a lot of things that are only done once, or where speed doesn't matter, or - these days - to _some_ extent where modern processor power can hide the inefficiency of the code. compact code is not necessarily more efficient. a simple example is an unrolled loop, which is less compact yet will run faster. another is having a large lookup table versus calculating a value each time. however, modern processors are far from simple, which is one reason why a compiler can do a better job of optimization than humans can. and then there's the issue of portability. anything written in a high level language can be recompiled for another processor, normally with little to no problem, whereas anything in assembler would need to be entirely rewritten from scratch. I suspect IrfanView, for example, is mostly coded in either assembler, or at least quite low-level code (or just possibly using an excellent optimiser - which are rare with ultra-high-level languages, such as scripting interpreters). it's highly unlikely any of it is in assembler. |
#63
|
|||
|
|||
Linux founder tells Intel to stop inventing 'magic instructions'and 'start fixing real problems'
On 7/17/2020 8:30 PM, nospam wrote:
In article , J. P. Gilliver (John) wrote: I remember - I _think_ it was in the last decade, but it might have been more - being startled when I spoke to a young computing graduate, to find he'd never done any assembler. At that time, after my initial double-take, I thought to myself: the field is big enough, that there'll be plenty of room for him, and in practice he'll probably never have any trouble finding interesting and well-paid employment. there is no need for assembler anymore, except in very rare circumstances. On PCs maybe. I bet some embedded stuff for ultra cheap mass market stuff is still done in assember, or something only very slightly higher level. Yes. Define "need". Compact code is noticeably more efficient - so runs faster. Yes, for a lot of things, the returns don't justify the effort - for a lot of things that are only done once, or where speed doesn't matter, or - these days - to _some_ extent where modern processor power can hide the inefficiency of the code. compact code is not necessarily more efficient. a simple example is an unrolled loop, which is less compact yet will run faster. another is having a large lookup table versus calculating a value each time. That depends on the length of the loop body and the number of iterations: crossing cache boundaries can extract performance hits. In fact, unrolling some loops can punish performance by factors of tens or even hundreds. If you carry your argument far enough and force paging you may cause arbitrary slow downs. As to look up tables the problems are the same. If all the values and indices fit in a small amount of storage (i.e. they are COMPACT), well and good. Otherwise all hell can break loose. however, modern processors are far from simple, which is one reason why a compiler can do a better job of optimization than humans can. Almost always true and more so as the years go by. and then there's the issue of portability. anything written in a high level language can be recompiled for another processor, normally with little to no problem, whereas anything in assembler would need to be entirely rewritten from scratch. Unless you are coding in C or one of its derivatives. There are enough places where a C compiler can choose the meaning of an expression (and not necessarily consistently) that you have to code in a modest subset of the language. And find a compatible compiler for portability. I suspect IrfanView, for example, is mostly coded in either assembler, or at least quite low-level code (or just possibly using an excellent optimiser - which are rare with ultra-high-level languages, such as scripting interpreters). Scripting interpreters are not a good example of an "ultra-high-level" anything. Most are, in fact, among the worst documented, least reliable, and least consistent from version to version of any software meant to be used by non developers of that software. Of course you may argue that they are completely consistent since documentation typically gives no serious details of what is supposed to be done in boundary cases. it's highly unlikely any of it is in assembler. -- Jeff Barnett |
#64
|
|||
|
|||
Linux founder tells Intel to stop inventing 'magic instructions'and 'start fixing real problems'
On 2020-07-17 17:32, VanguardLH wrote:
T wrote: And college was no better. I *hated* college. So freaking s-l-o-w. 3 months to read a book and take a test. Really? C'mon, that's ridiculous. And the class didn't even cover the entire textbook. Then they switched from quarters to semesters, so even longer to be bored. I tested out of as many classes as they permitted, and they wouldn't let me test out of more. They claimed the classroom experience must also be included for a well-rounded education. Yeah, sit in a chair and listen to a prof orate a textbook, and his oration interrupted by stupid questions. Well stated. When I hit college, I was a vet. I had no patience with condescending, arrogant, pompous blowhards. They taught me differently than the did the children that also attended the classes. I was responsible for getting two teacher removed for not doing their jobs. Several teachers said they liked teaching vets because there was no subterfuge. We were there for a reason the EXPECTED them to do their part. No having to herd cats. I also hate(d) school. The first day on campus after six years of military service and one medal, when I stepped foot on campus, I literally shook. "What in God name am I doing to myself?" I graduated in 4-1/4 years whilst working full time WITHOUT ONE SINGLE SOLITARY EXTRA CREDIT. I was working as a full engineer in my 3rd year of college. |
#65
|
|||
|
|||
Linux founder tells Intel to stop inventing 'magic instructions'and 'start fixing real problems'
On 2020-07-17 18:18, Brian Gregory wrote:
On 17/07/2020 17:31, nospam wrote: In article , J. P. Gilliver (John) wrote: I remember - I _think_ it was in the last decade, but it might have been more - being startled when I spoke to a young computing graduate, to find he'd never done any assembler. At that time, after my initial double-take, I thought to myself: the field is big enough, that there'll be plenty of room for him, and in practice he'll probably never have any trouble finding interesting and well-paid employment. there is no need for assembler anymore, except in very rare circumstances. On PCs maybe. I bet some embedded stuff for ultra cheap mass market stuff is still done in assember, or something only very slightly higher level. We build little computers with parts. Then went to CPU. All assembly code! |
#66
|
|||
|
|||
Linux founder tells Intel to stop inventing 'magic instructions'and 'start fixing real problems'
On 2020-07-17 17:10, VanguardLH wrote:
"J. P. Gilliver (John)" wrote: VanguardLH wrote: I think we used interns for 6 months: the contract length. Never again thereafter. Why did you use them in the first place - was it because of some form of state subsidy, of about that duration? I wasn't in the decision loop. At a weekly status meeting, our manager said, "Guess what?" followed by a groan. Whenever he said that, we'd get quiet waiting for yet another edict from management. Training (the same group that taught us) took care of classes, instructional CDs, and documentation but QA did the progress monitoring and tutoring to make sure the interns got up to speed in 2 weeks. We stretched it to 3 weeks to also train them on our QA procedures. They did okay during the training phase probably because it was similar to school, but more accelerated, like a seminar. However, When they were on their own to do the actual testing, and despite the retro tests were complete (no decisions to make, and previously reviewed with feedback from outside our group to make sure any tech could follow them), was when they got, um, slow and "lost". We changed from weekly status meetings to still doing those but with me going around to everyone (not just interns) to get a daily status update to see who needed more help, discover any snags, talk to the boss about possible resource reallocation, or gauge the severity of peril to our testing schedule. Maybe our expectation was too high. We had programmers that left because they couldn't take the stress or didn't have the flair for digging into a product to thoroughly test it. I got offered a programming position but declined because it was too boring. We had expection of getting and training new-hires, just as we were once, but the interns just never became adept. Could be they knew they were going back to just school and they'd be leaving us hence no motivation for long-term motivation (although there was the prospect of getting hired if they performed well). Would you keep going to the gym to stay healthy if you knew you were getting killed in 6 months? In my college, they mixed the upper tier and lower tier courses. Electronics 101 had about 200+ folks in it. Standing room only. At the end, there was only about 15 of us. We all knew each other by name |
#67
|
|||
|
|||
Linux founder tells Intel to stop inventing 'magic instructions'and 'start fixing real problems'
On 2020-07-17 21:06, Jeff Barnett wrote:
Scripting interpreters are not a good example of an "ultra-high-level" anything. Most are, in fact, among the worst documented, least reliable, and least consistent from version to version of any software meant to be used by non developers of that software. Of course you may argue that they are completely consistent since documentation typically gives no seriousÂ*detailsÂ*ofÂ*whatÂ*isÂ*supposedÂ*toÂ*beÂ* doneÂ*inÂ*boundaryÂ*cases. Perl 5 has wonderful documentation (PerlDocs). Raku's (Perl 6's) absolutely suck. They are written as a refresher for those that already know what they are doing. They are not completely useless, just really close to useless. And often have mistakes in them. I program a lot in Raku. I love the language, but not the docs. |
#68
|
|||
|
|||
Linux founder tells Intel to stop inventing 'magic instructions' and 'start fixing real problems'
In article , Jeff Barnett
wrote: I bet some embedded stuff for ultra cheap mass market stuff is still done in assember, or something only very slightly higher level. Yes. Define "need". Compact code is noticeably more efficient - so runs faster. Yes, for a lot of things, the returns don't justify the effort - for a lot of things that are only done once, or where speed doesn't matter, or - these days - to _some_ extent where modern processor power can hide the inefficiency of the code. compact code is not necessarily more efficient. a simple example is an unrolled loop, which is less compact yet will run faster. another is having a large lookup table versus calculating a value each time. That depends on the length of the loop body and the number of iterations: crossing cache boundaries can extract performance hits. In fact, unrolling some loops can punish performance by factors of tens or even hundreds. If you carry your argument far enough and force paging you may cause arbitrary slow downs. As to look up tables the problems are the same. If all the values and indices fit in a small amount of storage (i.e. they are COMPACT), well and good. Otherwise all hell can break loose. they were simple examples to make a point. they were not meant to be a treatise on every possible scenario. however, modern processors are far from simple, which is one reason why a compiler can do a better job of optimization than humans can. Almost always true and more so as the years go by. yep. and then there's the issue of portability. anything written in a high level language can be recompiled for another processor, normally with little to no problem, whereas anything in assembler would need to be entirely rewritten from scratch. Unless you are coding in C or one of its derivatives. There are enough places where a C compiler can choose the meaning of an expression (and not necessarily consistently) that you have to code in a modest subset of the language. And find a compatible compiler for portability. c is not an issue unless the programmer makes mistakes and ignores any compiler warnings. I suspect IrfanView, for example, is mostly coded in either assembler, or at least quite low-level code (or just possibly using an excellent optimiser - which are rare with ultra-high-level languages, such as scripting interpreters). Scripting interpreters are not a good example of an "ultra-high-level" anything. Most are, in fact, among the worst documented, least reliable, and least consistent from version to version of any software meant to be used by non developers of that software. Of course you may argue that they are completely consistent since documentation typically gives no serious details of what is supposed to be done in boundary cases. irfanview isn't using a scripting interpreter. it's highly unlikely any of it is in assembler. |
#69
|
|||
|
|||
Linux founder tells Intel to stop inventing 'magic instructions' and 'start fixing real problems'
In article , wrote:
We build little computers with parts. Then went to CPU. All assembly code! that doesn't make any sense. |
#70
|
|||
|
|||
Linux founder tells Intel to stop inventing 'magic instructions' and 'start fixing real problems'
One day a prof arrived just before his class, put his hat on his desk,
but got busy elsewhere. When he got back and very late for class, all the students had left. The next day he declared, "When my hat is on my desk, that's the same as I'm here." The next day the students came in, put hats on their chairs, and left. |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
fans start-stop-start when booting | [email protected] | Homebuilt PC's | 4 | November 21st 14 06:25 PM |
PC power on - start, stop, start, stop, etc - eventually powers up | spodosaurus | Homebuilt PC's | 10 | December 27th 08 02:55 PM |
Intel CEO tells us to buy a Mac | YKhan | General | 7 | May 28th 05 06:01 AM |
InfoWorld: Global Standards Are Key, Intel CEO Tells Chinese Execs | Dionaea muscipula | Intel | 2 | April 9th 04 07:30 AM |