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...

Try NopSCADlib for your Next OpenSCAD Project

Most readers of this site are familiar by now with the OpenSCAD 3D modeling software, where you can write code to create 3D models. You may have even used OpenSCAD to output some STL files for your 3D printer. But for years now, [nophead] has been pushing OpenSCAD further than most, creating some complex utility and parts libraries to help with modeling, and a suite of Python scripts that generate printable STLs, laser-ready DXFs, bills of material, and human-readable assembly instructions complete with PNG imagery of exploded-view sub-assemblies. Recently [nophead] tidied all of this OpenSCAD infrastructure up and released it on GitHub as NopSCADlib . You can find out more by browsing through the example projects and README file in the repository, and by reading the announcement blog post on the HydraRaptor blog . Some functionality highlights include: a large parts library full of motors, buttons, smooth rod, et cetera many utility functions to help with chamfers, fillets, precis...

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...