|
shaken or stirred?
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
|
Oxfords or Brogues?
Sent from my Amstrad PC 1640
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Tabs
iOS? Android? None of them.
Certainly not Mickeysoft anymore, so where is the question?
T-Rex, no less[^]
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
Soapbox - you trouble-maker. 
Everyone is born right handed. Only the strongest overcome it.
Fight for left-handed rights and hand equality.
|
|
|
|
|
|
Welcome, are you a singer?
|
|
|
|
|
Over the last year or so, I have enjoyed many of the articles that came my way courtesy of the X-Team weekly newsletter. This week's newsletter brought JavaScript Essentials: Why You Should Know How the Engine Works, which included a demonstration to drive home some great points about how modern JavaScript engines work, and how they can work against you unless your design takes into account how the engine that runs your carefully crafted code works.
As I read the article, I noticed that the example is something that I know intuitively is suboptimal. The article explained exactly what made it suboptimal, which confirmed the my intuitive suspicion. This caused me to realize how many times that such intuitive understanding has kept me away from many suboptimal design choices throughout my career. Though I don't often write in Assembly Language, apparently, my understanding of the machine is such that it helps me steer clear of many inefficient patterns without much conscious effort.
A long time ago, when I was in graduate school, I had the opportunity to work with an electrical engineer who was working on his master's degree, from whom I learned a great deal about how the CPU on the Sperry Univac 1100 that we used at The University of Alabama worked, and how to take advantage of that knowledge to write high performance code. Though we did most of our production work in Fortran, he encouraged me to learn Assembler, which I did, and I put that knowledge to use in the work that I did for the Center for Business and Economic Research.
Since then, I have made some effort to learn and use the assembler for almost every computer for which I have developed software. Indeed, the first job I had following graduate school was at a company whose programs, which ran on a Burroughs B-4700 mainframe, were written entirely in its assembly language. Since then, the only significant exception was the IBM System/34, for which I didn't have access to an assembler. That exposure to the assembler has paid dividends on every platform by enabling me to solve problems that would almost certainly have otherwise eluded me.
Though I prefer to use the highest level programming language that can express the solution of the problem at hand, there are countless times when my grasp of the underlying machine code that comes from learning the assembler for a CPU has enabled me to solve a problem quickly on my own, without having to wait for a specialist to find time to work with me on the problem.
To this day, I often find myself running the debugger in the Disassembly view, when the source view would almost certainly suffice. When I can get away with it, I stay there, even if I mostly hit F10 or F11 to execute the next instruction or function call, because I learn something useful from so many of these sessions.
For example, just this week, I needed to solve a problem that arose when I rewrote one of the first ANSI C functions that I ever wrote from scratch to make it thread-safe. That routine uses another of my early ANSI C functions that emulates the stream I/O routines in the standard C runtime library by treating blocks of memory as if they were file streams. Since the change caused that memory stream routine to return an error, I traced into it. Tracing in disassembly view, I noticed something in the calling routine that initially startled me; immediately after the stream I/O open routine returned, it copied the contents of the emulated FILE structure from the location in the stream I/O routine's address space into the address space of the calling routine, to populate the emulated FILE structure that was defined therein, and occupied memory within its address space.
Taking a closer look at the stream open routine, I noticed that its return type was FILE (actually emulated FILE), the structure, itself, rather than a pointer to it. I had forgotten that such an operation was even legal, but I was dismayed by how and why it works. Before I called the library update done, I rewrote that module, which I developed for that library, so that the opener allocates memory to store the structure from the default process heap, and returns a pointer to that memory. In the new version of the module, the other routines take an opaque pointer to the structure, and the close routine disposes of the memory that was allocated from the heap. The new routine is a more faithful emulation of the CRT routine whose interface it copied, and the inefficient memory copy is gone from the routines that use it. The new library, with its thread-safe routines, will soon find its way into a new GitHub repository.
David A. Gray
Delivering Solutions for the Ages, One Problem at a Time
Interpreting the Fundamental Principle of Tabular Reporting
|
|
|
|
|
David A. Gray wrote: The new library, with its thread-safe routines, will soon find its way into a new GitHub repository.
Don't forget to write a CP-Article for it  
I know what you say...
In the PLC world there have been improvements towards the high level languages too, but they (the improvements) were/are very slow.
5 Years ago... in a project. A function to find an object and bring it to the GUI. To be done we needed two nested loops, one for the data containers in each station and one for the data objects in the selected station.
High level code... 4 lines. Compile: 34 Kb translated code, cycle time increased by 10 to 15 ms every time the function was being called. Me... 
Cup of coffee, earphones, music, "do not disturb" sign on my desk, 2 hours work = code written in LAD? (english name for german AWL) which is kind of similar to assembly. Function 1,7 kb code, cycle time not visibly affected by the use of the function (meaning: impact < 0,5ms). My co-worker 
This project was done based on a previous project done by a previous employee, the difference, I got the other in legacy mode. I had to write this from the scratch, a couple of re-factorings later... the very same PLCs (Hardware) were handling 60 to 70% more data / functionality, and had a stable cycle time 30% faster than the base project.
Conclusion: High level languages are nice and can perform a real huge amount of things, but sometimes it is like trying to kill a fly with a bazooka.
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Nelek wrote: trying to kill a fly with a bazooka
Grasshoppers should do what they know to do best: Dig holes in the ground. If a fly needs to be killed, use the right tool[^].
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Nelek wrote: High level code... 4 lines. Compile: 34 Kb translated code, cycle time increased by 10 to 15 ms every time the function was being called.
Equally astounding about that 34 KB is the proportion of it that is composed of code pulled into the translation unit from the runtime library and other overhead, such as linkage editor fixup tables.
Nelek wrote: Cup of coffee, earphones, music, "do not disturb" sign on my desk, 2 hours work = code written in LAD? (english name for german AWL) which is kind of similar to assembly. Function 1,7 kb code, cycle time not visibly affected by the use of the function (meaning: impact < 0,5ms).
For code that runs often, that much of a performance improvement absolutely justifies implementing in assembly language. The skill is in divining which bits warrant the extra effort.
Nelek wrote: High level languages are nice and can perform a real huge amount of things, but sometimes it is like trying to kill a fly with a bazooka.
Indeed. However, my point in explaining about the function that returned a structure is that using the disassembly view in the debugger enabled me to identify a simple, mostly transparent change that eliminated a memory copy that happened every time the memory stream opener was called. Had I stayed in the source code view, that easily cured inefficiency would have gone unnoticed.
David A. Gray
Delivering Solutions for the Ages, One Problem at a Time
Interpreting the Fundamental Principle of Tabular Reporting
|
|
|
|
|
I'm happy you are not silicon, and are a human-carbon being with a rich experience you generously share, here ! I admire people who get down the stack.
cheers, Bill
«... thank the gods that they have made you superior to those events which they have not placed within your own control, rendered you accountable for that only which is within you own control For what, then, have they made you responsible? For that which is alone in your own power—a right use of things as they appear.» Discourses of Epictetus Book I:12
modified 13-Jul-18 15:12pm.
|
|
|
|
|
BillWoodruff wrote: Silicon units do not need to recite their resumes, and congratulate themselves on their own intuition
I think you missed my point, which was to draw attention to the benefits of understanding assembly language and how the CPU works, regardless of how many layers of abstraction there are between you and the CPU.
David A. Gray
Delivering Solutions for the Ages, One Problem at a Time
Interpreting the Fundamental Principle of Tabular Reporting
|
|
|
|
|
I apologize, David, if the first paragraph of my response failed at being humor: I'll remove it.
I meant what I said in the second paragraph !
cheers, Bill
«... thank the gods that they have made you superior to those events which they have not placed within your own control, rendered you accountable for that only which is within you own control For what, then, have they made you responsible? For that which is alone in your own power—a right use of things as they appear.» Discourses of Epictetus Book I:12
|
|
|
|
|
There's no need for such drastic measures, since I suspected as much. My remark about it was directed not at you, but at lurkers who might have missed the gist.
David A. Gray
Delivering Solutions for the Ages, One Problem at a Time
Interpreting the Fundamental Principle of Tabular Reporting
|
|
|
|
|
I picked up a new book at Barnes & Noble today:
Valley of Genius: The Uncensored History of Silicon Valley (As Told by the Hackers, Founders, and Freaks Who Made It Boom)^[^]
Decided to get it because it quotes the real people who were there and because of this great quote from Woz, which I had never read before. Makes a salient point.
Steve Wozniak: Look, I came up with the product that made Apple! If Steve Jobs had started without me, where would he have gone? Keep in mind, Steve tried to make four computers in his life -- with millions of dollars -- and they all failed: the Apple III, for marketing reasons; the Lisa, because Steve didn't understand costs; the Macintosh, which wasn't really a computer, just a program that looked like a computer and led to big problems later on; and the NeXT.
|
|
|
|
|
There is also the opposite side of it: Without Jobs, Woz likely would have stayed working as a board designer at HP. I suspect it was the combination of Jobs / Wozniak (not to mention the other folks involved) that really made Apple work in the early days.
|
|
|
|
|
This has proven to be the case many times. Two or more people together can have a synergy that could not be matched if they were acting independently.
|
|
|
|
|
Rick York wrote: Two or more people together can have a synergy that could not be matched if they were acting independently.
This is why I talk to myself. It helps me resolve issues when I get stuck. 
Everyone is born right handed. Only the strongest overcome it.
Fight for left-handed rights and hand equality.
|
|
|
|
|
|
raddevus wrote: If Gates had not convinced Apple to bring Jobs back...
Ummm... I don't recall ever hearing that one. I know Apple CEO Gil Amelio bought Next which brought Jobs back into the fold. I know Jobs maneuvered to get Amelio fired (he resigned before it happened). I know Jobs and Gates "made up" enough that Microsoft temporarily invested in Apple - basically keeping them afloat.
But I never heard that Gates had anything to do with Apple buying Next or bringing back Jobs.
EDIT: According to this Gates tried to talk Amelio out of buying Next because of Jobs.
The love-hate relationship between Bill Gates and Steve Jobs - Business Insider[^]
|
|
|
|
|
|
|
I thought Wozniak was more humble than that and actually smarter. Any tech company in the world would have loved to have Jobs to evangalise their product. That was his success - his failures are quite irrelevant except for the fact he did not give up. The world is full of brilliant engineers wondering why their door is not being beaten down in the rush to buy their new gadget.
Peter Wasser
"The whole problem with the world is that fools and fanatics are always so certain of themselves, and wiser people so full of doubts." - Bertrand Russell
modified 12-Jul-18 21:04pm.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
