hmpc

Similarly, if not performance-focused, I can wholeheartedly recommend Building Git[0], which walks you through building your own git clone in Ruby (although the language is immaterial).

[0] https://shop.jcoglan.com/building-git/

It's definitely possible to do correctly, but looking through the code for both crates it doesn't look like they take the necessary precautions (issuing a fence or using RDTSCP). Which is a little weird because at least quanta explicitly checks for RDTSCP support, but then doesn't seem to use it.

(I'm not a Rust expert and I'm on my phone though, so I might be missing something.)

Thanks for sharing this! I hadn't seen it before, I'll definitely add a mention in the post.

This approach is a smart way to get the same precision as the kernel without tying it to the vDSO implementation as in the post, so presumably someone at Google was worried about very similar issues. I also considered an implicit automatic refresh, but ultimately for my purposes controlling when to take the hit was more important than the slight increase in API complexity introduced by an explicit call.

This is explicitly called out in the post as well as the Intel instruction manual. Every codebase I've ever seen that reads the TSC either issues an LFENCE or uses RDTSCP.

In my benchmarks RDTSCP has a slight advantage, despite the slower latency on paper, because it doesn't fully serialise the instruction stream (later instructions can start executing, unlike with LFENCE). Whether the ECX clobber will outweigh that will depend on the situation.

You might've misunderstood the requirements. The time scale was 1-10 micros per component; 100 ns was the overhead per span we were aiming for.

In this case distributed tracing absolutely was the right choice. These were not simple computational tasks. The components were highly stateful and interconnected both on- and cross-host. Between this and the timescale, as well as the volume of events and the dollar-value impact of each potential failure (of which there were many), we needed real-time analysis capabilities, not a profiler.

Yep, I should probably have mentioned this option for completeness. In practice, however, it only saves you a few cycles/nanos and adds more complexity and failure points downstream.

Check the specification at the top. The range for x is [-1, 1]. For the range you provided the accuracy of the 0.5x alternative is reported as only 33%: https://herbie.uwplse.org/demo/570b973df0f1f4a78fe791858038a...

It depends on your use case, as always. Correctness is not always black and white (hence my favourite compilation flag, -funsafe-math-optimizations) and time complexity can be misleading (O(log N) with a large base is O(1) in practice), but a correct, theoretically optimal algorithm might still be leaving a lot of performance on the table. If you're a hyperscaler, a high-frequency trader, or perhaps a game programmer pushing the limits of the platform, small gains can accumulate meaningfully, as can the thousand cuts caused by small inefficiencies spread out over the codebase.

There's an interesting comment on this over on Lobsters: https://lobste.rs/s/e4y5ps/two_studies_compiler_optimisation...

(Author here)

It all seems very brittle, though. And that something has gone very wrong with our ecosystem of tools, languages, and processes when it becomes advisable to massage source until specific passes in a specific version LLVM don't mess things up for other passes.

I would say the main takeaway is actually to not do that, precisely because it's brittle, difficult to understand, and can backfire by making things harder for the compiler. As I point out at the end, the vast majority of developers will be better served by sticking to common idioms and making their intent as clear as possible using language facilities, rather than trying to outsmart the compiler or, conversely, relying excessively on the optimiser as a magic black box.

That being said, I do find it helpful to understand the broad strokes of the optimisation pipeline (things like "callees are optimised before callers", "maintaining invariants enables more simplifications", or "early simplifications are better") to make the most of it. Like with any other tool, mastery means letting it do its job most of the time but knowing when and where to step in if necessary.

Don't you need your read to be line-oriented to avoid breaking up lines?

Full disclosure: I work for Veniam on connected vehicle technology, including LTE, Wi-Fi, and DSRC stacks.

Unfortunately there's also still no agreement on what 5G will actually be, what technologies it will entail, or how it will be deployed. Of course, since none of this is defined yet, there are also no guarantees on what performance will be achievable in practice.

The industry will need to solve this issue long before 5G is widespread. The solution will likely involve DSRC, C-V2X, or LTE-V/LTE Direct, which are tailored for the vehicular communication use case (involving both vehicle-to-vehicle [V2V] and vehicle-to-infrastructure [V2I]). It's unlikely a single technology will be able to handle all the challenges of a V2X scenario (highly mobile nodes, congestion, low SNR, requirements for sub-millisecond connection times), and so a second connection management layer will have to be built on top of multiple existing PHYs to enable simultaneous low-latency, high-throughput, and secure communications.

(Note that the linked article is actually about in-vehicle communication, however.)

Backticks are discouraged for any new scripts, since they complicate nesting, quoting, and escaping, besides being graphically less explicit. See also http://mywiki.wooledge.org/BashFAQ/082. The Open Group also discourages backticks: http://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xcu_....

Actually no. From the manpage:

Use "-C -" to tell curl to automatically find out where/how to resume the transfer. It then uses the given output/input files to figure that out.

Veniam | Mountain View, CA/Porto, Portugal/Singapore | Multiple openings | ONSITE

We are looking to fill several openings across Engineering, Sales, and Management: https://veniam.com/jobs/. We have opportunities for cloud, analytics, front-end, hardware design, and embedded software work.

Veniam is building the Internet of Moving Things by turning vehicles into WiFi hotspots and building networks of connected vehicles that expand wireless coverage and collect terabytes of urban data for smart city applications.

As a member of our team at Veniam, you will have the opportunity to work in fast moving teams of 3-5 people, work closely with our Customer Success teams and often directly with key customers worldwide. We are organized in changing mission-driven teams that deliver continuously and you will have the opportunity to work on something new every few weeks.

If you're interested drop me a line at hcabral@veniam.com!

You can also remove all the "STCP | PortoDigital" networks in Porto, Portugal, which are WiFi hotspots in the public buses. Interesting map!

(Disclaimer: I work for the company who implemented that network.)

This is the service supervision approach, which is indeed the best, avoiding race conditions and nasty polling. If you really must monitor processes which you cannot parent, at least under Linux you can do this using ptrace to sort-of-reparent the processes (as long as you have CAP_SYS_PTRACE or your ptrace scope is set to 0 in Yama), with waitpid to monitor all of them.

Veniam, Portugal - Software Engineer - http://www.veniam.com/

Veniam just raised a $4.9M series A to build the networking fabric for the Internet of Moving Things (http://techcrunch.com/2014/12/02/veniam-picks-up-4-9m-to-tur...), and we are looking for a Full-Stack Software Engineer to help us.

Someone with entrepreneurial spirit who is different, drives change and shares our passion for developing cutting-edge products that people and businesses love and use everyday.

Critical thinking, deliberate problem solving, disruptive mindset, and excellent communication are essential qualities, as you will be working in an exceptionally talented team with know-how across different disciplines, constant learning, boundless creativity, and outstanding execution – always in tandem with our headquarters in Silicon Valley.

If this is you, please share your CV with us at jobs@veniam.com

Target skills:

* Node.js

* MySQL

* MongoDB & Redis

* Computer Networks (!)

* AWS

* and excellent English.

Unless I misunderstood, that's what the TIMER_ABSTIME option is for. This is actually what I use for soft real-time loops, when I'm concerned about both drift and jitter.

You can already do this in POSIX.1-2001-conforming systems like Linux using `clock_nanosleep` (http://man7.org/linux/man-pages/man2/clock_nanosleep.2.html).

Veniam, Portugal - Software Engineer - http://www.veniam.com/

Veniam just raised a $4.9M series A to build the networking fabric for the Internet of Moving Things (http://techcrunch.com/2014/12/02/veniam-picks-up-4-9m-to-tur...), and we are looking for a Full-Stack Software Engineer to help us.

Someone with entrepreneurial spirit who is different, drives change and shares our passion for developing cutting-edge products that people and businesses love and use everyday.

Critical thinking, deliberate problem solving, disruptive mindset, and excellent communication are essential qualities, as you will be working in an exceptionally talented team with know-how across different disciplines, constant learning, boundless creativity, and outstanding execution – always in tandem with our headquarters in Silicon Valley.

If this is you, please share your CV with us at jobs@veniam.com

Target skills:

* Node.js

* MySQL

* MongoDB & Redis

* Computer Networks (!)

* AWS

* and excellent English.

𝐏𝐨𝐫𝐭𝐨, 𝐏𝐨𝐫𝐭𝐮𝐠𝐚𝐥 - 𝐒𝐨𝐟𝐭𝐰𝐚𝐫𝐞 𝐄𝐧𝐠𝐢𝐧𝐞𝐞𝐫 - 𝐕𝐞𝐧𝐢𝐚𝐦 http://www.veniam.com/

We are looking for a Full-Stack Software Engineer to help us build the networking fabric for the Internet of Moving Things.

Someone with entrepreneurial spirit who is different, drives change and shares our passion for developing cutting-edge products that people and businesses love and use everyday.

Critical thinking, deliberate problem solving, disruptive mindset, and excellent communication are essential qualities, as you will be working in an exceptionally talented team with know-how across different disciplines, constant learning, boundless creativity, and outstanding execution – always in tandem with our headquarters in Silicon Valley.

If this is you, please share your CV with us at jobs@veniam.com

Target skills:

* Node.js

* MySQL

* MongoDB & Redis

* Computer Networks (!)

* AWS

* and excellent English.

Are you in the US? Because in Europe all electrical products are certified under strict EU directives, and (at least in my country) there are routine inspections to ensure that all products for sale comply. You can walk into just about any supermarket and get a pretty trustworthy power strip, electrical appliance, or what have you.

  Message body
  just as in <subject> use imperative, present tense: “change” not “changed” nor “changes”

I've been doing digital design for Xilinx FPGAs, as well as IC design, for a few years now and never had any trouble with the Linux toolchain. I can't even imagine switching to Windows and trying to automate the build (not saying it's not possible, it just seems a lot more convoluted).

It's true that smaller vendors like Lattice seldom provide Linux software, but it's also rare to find bigger shops (as opposed to hobbyists) who don't use Xilinx or Altera exclusively, and Linux at that.

Agreed. The problem is not CS, it's the popularisation of CS as a gateway into the wonderful and high-paying world of software ninjas/rockstars/gurus/[hype du jour]. Transforming CS into preparation for software development careers would be akin to redoing engineering schools to teach students machining skills: important, yes, but that's what vocational/trade schools are for. If you're going into college, suck it up and learn your math. For everything else there's the documentation.

To add to this, it's not just Canada either. Here in Portugal we have what we call Ordens, not just for engineers but for physicians, lawyers, and other professions. The title of Engineer is also reserved for members of the Ordem, but you only need a degree from an accredited institution.[0] While this does not have much of a legal implication for software engineering, civil engineering projects can only be signed off by members of the Ordem, given the nature of the field.

[0] Lawyers, on the other hand, undergo very extensive examination, and they can only practice law if they are members of the Ordem.

Did you run a post-PAR (timing) simulation on that? On designs with low timing slack or large area occupation this is really important, otherwise you may easily violate setup/hold time constraints in what are usually very nondeterministic ways. This is, in fact, one of the reasons why ASIC development is ~80% verification.

We had a bug of the kind once, where a Microblaze core would fail to boot the Linux image after what seemed a trivial modification in the peripheral code, but it turns out we were packing the logic so tightly that this change blew the timing on some critical net. Ah, the joys of digital design.

This is indeed a common use case for temperature sensors in embedded devices, and I very much doubt there isn't one in the S5. Temperature sensors are included in pretty much all inertial sensor dies nowadays, both for offset/drift calibration and thermal shutdown protection. It's more likely that Samsung simply removed application-level access, although I don't know why they would do so.

This is a good distinction to make. The term "signal" implies an information carrier (as in the expression "the signal in the noise"), which in light of information theory can be interpreted to mean an unknown variation (as modelled by, e.g. a stochastic process). This is philosophically distinct from the interpretation of a mathematical function as analytically defined and completely known.