|
Profile picture has water purifier so ....
|
|
|
|
|
There it is, the ironic and the prosaic.
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 13-Jul-18 4:35am.
|
|
|
|
|
Ok. What cooking?
Bryian Tan
|
|
|
|
|
Hello!
Welcome to the site, how are you today?*
* I never was much good at small talk
Sent from my Amstrad PC 1640
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
OriginalGriff wrote: * I never was much good at small talk
Who would tell it... you are the most prolific poster in CP
Seeing the profile... this smells of S&A candidate
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.
|
|
|
|
|
Maybe they really like water coolers? 
|
|
|
|
|
Nelek wrote: this smells of S&A candidate
It does a little, but ... benefit of the doubt and all that!
Nelek wrote: Who would tell it... you are the most prolific poster in CP
Yeah, but that breaks down into a three types:
i) Technical - I know what I'm doing and that's easy to work with.
B) Like-minded people - we have something in common, so it;s relatively easy to keep a conversation going.
0) Humorous response - and I can take a couple of hours to think about it, just Like I did with this reply to you.
Meet somebody at a social event and it's "Erk ... where do I start?" 
Sent from my Amstrad PC 1640
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
OriginalGriff wrote: benefit of the doubt and all that!
That's why I said: "smells of" and not "is"  
OriginalGriff wrote: Yeah, but that breaks down into a three types:
i) Technical - I know what I'm doing and that's easy to work with.
B) Like-minded people - we have something in common, so it;s relatively easy to keep a conversation going.
0) Humorous response - and I can take a couple of hours to think about it, just Like I did with this reply to you.
Meet somebody at a social event and it's "Erk ... where do I start?"
I kind of know what you mean, but I am Spanish, we have "small talk" and "talk non-sense" written in our genetic code
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.
|
|
|
|
|
Well - you may need to just practice a bit. Maybe with a small audience.
Perhaps a few willing sheep for a starter . . .
(I don't understand - this seems to be going terribly wrong)
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
Hi Pearl !
Tabs or spaces ? (Tabs are better)
iOS or Android ? (iOS mwawawahh I hope you are not one of these Apple fanboys)
Microsoft or Linux ? (True question...)
Veggie or T-Rex ? (Save the plants, don't be vegan)
|
|
|
|
|
You forgot the really important questions:
i) emacs or vi?
0) K&R or Whitesmiths?
Proper types or var?A) VB or death?
Sent from my Amstrad PC 1640
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
|
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.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
