HN user

chapplap

28 karma
Posts0
Comments14
View on HN
No posts found.

Yes, this is a very good point. Low-end application processors capable of running Linux are also very cheap now and it is easy to build a minimal system for around a few bucks (eg. Allwinner F1C100s, although it does not have an Ethernet MAC built in). Not great for hard real-time stuff, but if the requirements there are limited a separate microcontroller could work.

You can install the extension directly from a cloned copy of the Github repo (basically as if you were the extension developer). No auto-updates or anything since it's just loaded from some files on your disk. Chrome will nag you about it from time to time though since getting people to install unsigned extensions is a common attack vector.

It's not too complicated, at least in theory. Typically you decide a lens model ahead of time that has some unknown calibration parameters (eg. focal length, skew, radial/tangential distortion). For a given lens/sensor system, the calibration parameters can be determined ahead of time by taking pictures of a calibration pattern (checkerboard, AprilGrid, etc.). The calibration pattern provides some ground truth distances between multiple points in the image. An off-the-shelf non-linear solver is then used to solve for the unknown calibration parameters.

This usually provides acceptable results for applications like correcting lens distortion, even across multiple instances of the same lens. However, sometimes better accuracy is needed - either because the lens is very cheap and inconsistent between different examples or for applications like SLAM where better camera calibration translates directly into better results. In that case there are techniques like online calibration to tweak the calibration parameters on the fly.

This is about bitstream encryption, so there is an expectation of confidentiality. The keys needed to decrypt the bitstream are stored in nonvolatile memory on the FPGA itself. Assuming that it is implemented correctly (evidently not in this case), it is impossible to decrypt the bitstream without analyzing the FPGA die itself, using tools that are usually beyond what a casual attacker might have. It probably won't stop a nation-state from figuring out how to read out your FPGA design, but it will probably slow down your competitors.

That's not exactly true once you have to deal with vector extensions like AVX-512. It's quite a pain to write by hand (C intrinsics) and many of the ways to abstract it away end up giving you a GPU-like programming model (eg. Intel ISPC).

Plus, this has largely been tried before with Xeon Phi and it didn't end so well.

Huge vector units like AVX-512 are mainly useful for workloads that need huge amounts of RAM that you just can't get with a GPU, or for workloads that are very latency sensitive and incompatible with GPU task scheduling because they are in some other CPU-bound code.

Yes, they are accepted on the application. Many of the undergrads at MIT qualified for the AIME. A substantial number qualified for the USAMO or IMO as well - just look at the Putnam results every year.

Frankly, in order to stand out among MIT applicants by demonstrating some sort of mathematical ability on these exams, the minimum is probably USAMO qualification (top 270 of ~200k AMC takers). Otherwise it's a nice thing to have but not particularly unique. Even then I know a reasonable number of USAMO qualifiers who have been rejected.

Source: was a MIT undergrad < 5 years ago

It was removed in Skylake, not Broadwell. Ice Lake reintroduces the FIVR again. The inductors are now in the package substrate (rather than discrete inductors on the package or the weird 3DL module in Broadwell-Y) and efficiency at low power is improved. The latter is obviously extremely important for mobile workloads.

For a true turn-key solution you probably need the entire stack from sensors up to software. Intel's RealSense cameras (the T265 specifically) is probably the most reasonably priced option for a hobbyist with reasonable APIs. Visual and visual-inertial SLAM are not at a point where open-source packages are robust and easy to use with an arbitrary sensor stack and environment.

If you only have 2D motion and can spend more money or mess around with unsupported hardware (salvaged Neato vacuum) a laser rangefinder is also a decent option.

It's actually a lot larger if you look at vector registers - AVX registers are 32 bytes each and there are also ~168 of them in modern AMD and Intel CPUs, resulting in 5KB of registers. With AVX-512 the number is 10KB!

This just means Geekbench isn't good at scaling to multiple cores. It could be the workload or the implementation. If you have the right workload and a good implementation, modern processors do scale reasonably well (all numbers with Threadripper 3970X):

Cinebench R15: 206 single, 7302 multi, 35.4x scaling

POV-Ray: 9:02 single, 0:19 multi, 28.5x scaling

The scaling can be greater than the number of physical cores due to SMT. On the other hand, turbo clocks increases the single-core speed by 10% or more on most CPUs.