Skip to main content

Where The Work Is Really Done – Casual Profiling

Once a program has been debugged and works properly, it might be time to start optimizing it. A common way of doing this is a method called profiling – watching a program execute and counting the amount of computing time each step in the program takes. This is all well and good for most programs, but gets complicated when processes execute on more than one core. A profiler may count time spent waiting in a program for a process in another core to finish, giving meaningless results. To solve this problem, a method called casual profiling was developed.

In casual profiling, markers are placed in the code and the profiler can measure how fast the program gets to these markers. Since multiple cores are involved, and the profiler can’t speed up the rest of the program, it actually slows everything else down and measures the markers in order to simulate an increase in speed. [Daniel Morsig] took this idea and implemented it in Go, with an example used to demonstrate its effectiveness speeding up a single process by 95%, resulting in a 22% increase in the entire program. Using a regular profiler only counted a 3% increase, which was not as informative as the casual profiler’s 22% measurement.

We got this tip from [Greg Kennedy] who notes that he hasn’t seen much use of casual profiling outside of the academic world, but we agree that there is likely some usefulness to this method of keeping track of a multi-threaded program’s efficiency. If you know of any other ways of solving this problem, or have seen causal profiling in use in the wild, let us know in the comments below.

Header image: Alan Lorenzo [CC BY-SA 3.0].



from Hackaday https://ift.tt/2GAfkzF

Comments

Popular posts from this blog

How To Play Doom – And More – On An NES

Doom was a breakthrough game for its time, and became so popular that now it’s essentially the “Banana For Scale” of hardware hacking. Doom has been ported to countless devices, most of which have enough processing ability to run the game natively. Recently, this lineup of Doom-compatible devices expanded to include the NES even though the system definitely doesn’t have enough capability to run it without special help. And if you want your own Doom NES cartridge, this video will show you how to build it . We featured the original build from [TheRasteri] a while back which goes into details about how it’s possible to run such a resource-intensive game on a comparatively weak system. You just have to enter the cheat code “RASPI”. After all the heavy lifting is done, it’s time to put it into a realistic-looking cartridge. To get everything to fit in the donor cartridge, first the ICs in the cartridge were removed (except the lockout IC) and replaced with custom ROM chips. Some modifica...

The Flexible Permanence of Copper Tape Circuits

Somewhere between shoving components into a breadboard temporarily and committing them to a piece of protoboard or a PCB lies the copper tape method. This flexible Manhattan-style method of circuitry formed the basis for [Bunnie Huang]’s Chibitronics startup, and has since inspired many to stop etching boards and start fetching hoards of copper tape. [Hales] hit the ground running when he learned about this method , and has made many a copper tape circuit in the last year or so. He offers several nice tips on his site that speak from experience with this method, and he’ll even show you how to easily work an SMD breakout board into the mix. Generally speaking, [Hales] prefers plywood as the substrate to paper or cardboard for durability. He starts by drawing out the circuit and planning where all the tape traces will go and how wide they need to be. Then he lays out copper traces and pads, rubs the tape against the substrate to make it adhere strongly, and reinforces joints and laps w...

The Newbie’s Guide To JTAG

Do you even snarf? If not, it might be because you haven’t mastered the basics of JTAG and learned how to dump, or snarf, the firmware of an embedded device. This JTAG primer will get you up to snuff on snarfing, and help you build your reverse engineering skills. Whatever your motivation for diving into reverse engineering devices with microcontrollers, JTAG skills are a must, and [Sergio Prado]’s guide will get you going. He starts with a description and brief history of the Joint Test Action Group interface, from its humble beginnings as a PCB testing standard to the de facto standard for testing, debugging, and flashing firmware onto devices. He covers how to locate the JTAG pads – even when they’ve been purposely obfuscated – including the use of brute-force tools like the JTAGulator . Once you’ve got a connection, his tutorial helps you find the firmware in flash memory and snarf it up to a file for inspection, modification, or whatever else you have planned. We always apprec...