162 karma · joined January 21, 2021
Just could the two sets of coils be optimized for their own purposes?
Just guessing, does ZF mostly put out induction motors, and they need to make them look less unfashionable so that people choose them for new designs?
And agreeing with the other reply, nobody jumps up and down with joy when choosing an error handling crate. You pick the right poison for the job and try not to shed a tear for code beauty as you add in error handling.
I'd guess the physical CPU package of an i386 would cope just fine with the few (hundreds?) of gates toggling in that small loop.
I wonder if it might be possible to do on a modern FPGA, if you artifically create some unstable circuit and pack deliberately it in a corner of the die?
There's probably some AVX512 concoction that would be the closest equivalent on a modern X64. There's probably an easy experiment -- if that concoction makes CPU freq drop and also makes whole-package thermals drop, it /could/ be due to localized die heating.
First and most important, the title claims these are safety-critical rules, but the conclusion says that they are only being used on mission-critical projects. I get the feeling that there might have been some late-change copyediting done here, as the content is far too generalizing to be taken seriously in any specific safety critical context, and hopefully the author would have known that.
* Agree that many safety-critical coding standards are a grab-bag of sometimes dubiously-valuable rules.
* Agree with the implication that stylistic guidelines are almost totally worthless, and may distract reviews from their core task of finding functional errors.
* The document states that manual review of large cases may be infeasible, but I have never worked on a project that didn't mandate it. Drudgery goes hand-in-hand with safety-critical, and mindnumbing close review is an accepted element of this.
* Agree that less rules is good, but the author doesn't justify why 10 rules is the best. Unfortunately this is a field where correctness trumps easiness or simplicity, and any class of error with unacceptable risk to life/limb must be prevented. Thus any ruleset cannot justify itself simply because it is small.
* In fact, there are many wordings in this document that are generally-unacceptable because they are admitting incompleteness in the general case (and therefore unsuitability for any safety-critical purpose), such as "Although such a small set of rules cannot be all-encompassing" or "In return, it should be possible to demonstrate more convincingly that critical software will work as intended"
commentaries on specific rules:
* rule 4: "No function should be longer than what can be printed on a single sheet of paper". In my experience, readability is not always improved by limiting function length. The main goal of safety-critical be correct (and hopefully be obviously so). Sometimes splitting up code is harmful to this. (also this is actually a stylistic rule of the kind rejected in the 2nd paragraph of the document.)
* rule 5: In the safety-critical domain, defensive checks and "assertions" are usually considered at low-level-design. It's generally unacceptable for a coder to "just" insert defensive behaviours into the implementation, because all such behaviours must be analyzed for correctness. I don't disagree with the idea behind this rules, but a coding standard is the wrong place for it.
Or the same but for testing some verilog/vhdl CPU implemetation in a simulator?
Or since it's only 500SLOC, maybe it's just for fun!
Otherwise I agree with you, that library code should not fail/crash/exit(1) just because of some judgement about recoverability, and out to clean up after itself before passing control back to the caller. If the user wants to fix some ENOSPC deep in my library by shelling out to "rm -rf /" and then trying again, that's fine by me, and this should be reflected in the API.
The flow of responsibilities is strictly hierarchical. If Boeing specified to to their outsourcers that the software should have read from two sensors, then the outsourcer would be 'in the wrong' if they didn't implement that. With a strict interpretation of the rules Boeing doesn't necessarily have to check their outsourcer's work (In Safety-Critical the outsourcer has not just a commercial but also a moral obligation to perform all actions with competence)... But at the same time, because Boeing retains overall responsibility for its products no matter who it subcontracts to, it would be a mistake to not double check the work.
So to at least some extent (at least with moral-tinted glasses), it doesn't actually matter whether or not the fault was introduced by the subcontractor or not. Boeing is responsibility either way, Answering your question only tells us if the subcontractor is also at fault.
It's very important to note that in the Aerospace world, the subcontractor's moral duty only requires them to do exactly what they're told to do (assuming that the subcontractor was only reponsible for software design and not systems design). If Boeing told them to use one sensor, then the subcontractor has done nothing wrong if they failed to notice that this was fundamentally unsafe.
I think it's possible to accidentally use that straw man to justify fears when looking at embedded rust.. But as other people have pointed out in this thread, just because rusty interrupt handlers look weird doesn't work any better or worse than one written in C.
I think there is another side to this coin though. IMO there are too many embedded shops that overlook reliable 3rd-party code in favour of spending man-hours growing their own code from seed instead. Or if not that you spend days debugging some greybeard coworker's "Oh I think I wrote something like that 25 years ago for a PDP-11, I'll just email it to you.."
But to be honest I don't really disagree all that much -- As much as the embedded world needs to keep up with the times, there's no way that the level of audit required for a reliable embedded project just can keep up with how quickly crates are being changed.
> 2. A big departure from how things used to be done in this world.
Sometimes I cringe too when takes a massive server board with 9999GB of RAM and a 4g modem and calls it "embedded" just because they screwed it to the side of a helicopter... But if the root question is "will rust be viable on a puny AVR" I hope that the answer is definitely yes.
One example in my head individual strings that need to be constructed dynamically but live for the lifetime of the application (better to leak it with Box::leak or lazy_static! than pollute all code with lifetimes)
Another is writing in lifetimes for single purpose objects that live on the stack and might only ever get passed by ref into a single function and then get destroyed soon after.
Lifetimes are super important in rust and are a core part of the language, but in such degenerate cases they take up a lot of programmer effort for little benefit. In my head a "automatic" solution such as GC /could/ have a home in the language. Perhaps this would make rust a slightly better fit for really complex monolithic GUI apps (word processing, spreadsheets, CAD) where full GC would be performance-onerous but data lifetimes would be too complex for rust's strictly ordered lifetime concept
tldr; I've never read Overshoot either but I thought the post had an interesting perspective
In short, what we see in our graduates' teaching is a wrong-assumption that VHDL/verilog design is a bit like designing for 74-series chips, where you work out that you need to splat down a load of and/or/not gates and individually wire them up to some flipflops. This is reflected in section 18 of the problems, where students are asked to design simplistic low-level entities (sregs, muxes, and a single transparent latch). This is wrong because the true building blocks in the bottom of an FPGA are not individual and/or/not gates so there's no use in designing as if they were.
This leads to a situation where people have done their VLSI/FPGA module at university but they arrive without knowledge of core fundamentals such as: * Not clocking flops with data * Design for even mild levels of concurrency (it's common for courses to never get students to make two FSMs talk to each other even in the same clock domain -- pretty sure this document doesn't do this in section 18) * Thus everyday problems such as race conditions and deadlock will never have been covered.
IMO the very-incomplete nature of such courses also which attempts to pile concepts on top of each other too quickly without adequate explanation means that people come out of courses without really understanding how little of the basics that they know.
I accept that universities only ahve so much time to teach their students, and there is little academic pedagogical value in spending time on specific technologies, but the general poor approach could definitely be a lot better.
tldr; I agree that there hasn't been any revolutionary development in HDLs, but most universities missed the mark on teaching the basics when they first wrote their FPGA courses in the 1990s, and they haven't got much better since.
(P.S. if anyone wants to create a HDL without the crippling expressiveness flaws of either VHDL or verilog, I will personally transmute myself into a solid gold toilet especially for them)
Section 17 is mostly testing for rote learning, I'm guessing these questions are taken from some university course?
My favourite quesiton is 18.a) "Verilog Syntax/compile errors" which asks you to spot all the mistakes (while ignoring behaviour) and hint at a fix -- but since you're allowed to ignore all behaviour a valid (and reasonable) fix is actually to delete it all.
Beyond these superficial issues I'm mostly interested because my company takes in a lot of EE graduates for beginner FPGA roles, and in our experience almost all undergraduate instructive material is 30 years out of date. Almost all graduates still seem to get taught that VLSI design is done by manually instantiating combinatorial gates and D type flip flops.
And in honesty, I think this document falls into the same trap, section 18 asks the learner to design a transparent latch as a single module. It's very rare to want put a transparent latch in an FPGA, and you'd never dedicate an entire entity to describing one. It also asks for an 8-to-1 mux, a 4 bit shift register, and a 16 bit shift register.
However I think question 18.f) "FSM – Verilog Design of a Crosswalk Controller" is actually a very good example of the right sort of question (for, say midrange/advanced beginner), which will focus the students' attention on "normal" RTL design. Specifically I like that is requires specific clock timings (assert X for 32 clock cycles, assert Y for 10 cycles), as I think off-by-one timing errors in FSMs are a very common problem for beginners.
A more difficult extension (perhaps a part of student's first introduction to concurrency in an FPGA) would be to design a crosswalk controller with slightly more complexity.. maybe multiple buttons or multiple junctions or whatever.
Could such an algorithm ever find a duplicate between say a GIF (every frame is a keyframe) vs any modern codec with very few keyframes?
(or is this optimization specifically for videos known the be encoded with the exact same codec, and specifically with a static keyframe interval?)
Practically you can only expect such a tool to match up "reencodings" from one format to another.
Because of this IMO it's worth including the video length as a separate field within the hash. That way when you are doing a search you can sort the videos by length then only calculating the hamming distance for videos of similar length (a short video will never be a duplicate of a long one even if the perceptual hashes are close)
Unfortunately when all videos are the same length this doesn't change the O(n*2) time complexity, but assuming that they are not, this optimization should give a significant search time benefit and false positive reduction for large datasets.
I haven't actually checked what the author is doing, but for the sake of not having to decode entire videos (very CPU intensive) it's worth limiting the hash generation process to a small portion from the start of the video (somewhere between 30 seconds and 5 minutes has worked for me depending on the content). As well as being saving time this helps you detect reencodings where the time base is slightly altered (the frames will diverge more and more as time goes on)
(just adding some of my own experience from my own similar video hashing project!)
edit: inb4 someone complains about O(n*2) and mentions BK trees, for numbers up to ~500k hashes in my own testset a BK tree has always been slower than doing the naive search over a neatly aligned stripe of sorted-by-video-length hashes in memory. (Maybe I need to learn how to do memory arenas for cache locality) (or maybe I need to make my own video hashes be not 500 bits long)
Are we genuinely scared by the idea of getting a prion disease? Is there an actual risk of a prion epidemic? ..or putting my Freud hat on, does everyone on HN share a weird masochistic fetish about 'the next big pandemic'?
For my part I don't really get it, but then maybe it's because I'm british and for us prion diseases have been boring (or rather the news isn't interested in prion diseases) since mad cow disease stopped being a thing 20 years ago.
GWR's PR might be expecting some a newspaper to release a inflammatory story like "Foreign built trains are so dangerous that they will explode if the hit a bumblebee", and so they will try and put out preemptory statements trying to guide perception and downplay the severity of the situation.
And the media will be expecting GWR's PR to be putting out equally disingenuous releases like "we redefined the metric system for the purposes of measuring cracks and now all the cracks are within acceptable tolerances", so they'll be trying to guide perception to make it as hard as possible for GWR to do that.
Maybe I'm too cynical but but given that this is a fairly new story, I'd assume that GWR's statements would be entirely doublespeak as you say, and media fearmongering to be entirely speculation. There hasn't been enough time for anyone to do enough sleuthing to work out what's really happening.
I guess we'll find out in time whether this is really a big problem or just a flash in the pan. Being a safety critical engineer I'm much more interested in the nature of the problem rather than the scale of the disruption, but quite often the media stops being interested as soon as the problem is fixed. So unless this ends up being a long disruption (like boeing's recent groundings) I guess we'll probably never know.
I guess the article is more trying to make a statement along the lines of "here's how you benefit if you know python and pretend that means you know CPP too", (which seems like a fairly valid way to suck people into learning CPP to me)
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
I wonder how you can characterize the difference in speed between the two languages. I think I read somewhere that in the reference implementation of ruby, calling a method in the general case can require several hash table lookups to find the implementation associated with the name of the method. Is that mostly the same in python as well?
If you add opt-level=3 to the [profile.release] section, you might be able to speed up your rust code a little more.