CthulhuOvermind
CthulhuOvermind on Hacker News
I think there is no answer that doesn't involve sign-offs on certain things.
In the situation you described, we resorted to fully randomizing everything, and then adding constraints to ensure it remained legal. This is a tedious process, one that leads to multiple false-positive failing tests.
However, the opposite situation, writing constrained stimulus from the beginning, leads to gaps where you didn't think of randomizing something, or you over-constrained it.
It's similar to a top-down vs down-up approach, only one is difficult and tedious and riddled with false positives, whereas the other one is easier and simpler, but can hide bugs.
In the face of issues like what you said, we implemented randomized interface behavior. Interrupts are always meant to be program-order invisible, so you can randomize those (imagine, 100 interrupts back to back, or 1 every N cycles where N is random but smaller than 5 or 500 etc). Pure random isn't interesting on its own. You need controlled randomness. From that point, you have to then start adding constraints for illegal/impossible situations, and you have to be extremely careful about these. We found a bug a week before tapeout when a senior architect forced a junior engineer(wonder who this is) to add a constraint. He used his seniority to sign it off, without going through a group review, and it was a mistake.
Hardware is a long and tedious process. CPU design is an extra level of difficult on top.
In my field, it is routine to hire people in late 40s/50s to make CPUs. I'm in my late 20s, and viewed as a weird specimen. In my career I've made a armv8 CPU and now work RV64.
It takes a couple of years to get a guy from uni into working shape. And that's just to teach him how to do 1-2 tasks in his field. If verification, this usually is coverage specification and test writing. Combine this with a cpu project duration average of 5ish years and it's quickly evident that you won't beat someone with a startup.
In my office today, in a team of 10, no one, other than me is under 40.
A custom OS does not suprise me in the slightest, considering there are custom ARMv8 CPU's in development as well
I like your suggestion about viewing this as same-sex couple situation. I wrote my post specifically gender-neutral so as to prepare for the inevitable accusation of sexism, and then reveal that in my example the female was the perpetrator. But I think your opinion is much better
In the example I gave earlier, the female has obtained consent from her partner. The male changes his mind half-way through but does not stop or act in any different way.
In cases such as these, my understanding(and gut feeling really) is that since knowledge of consent is what makes an action legal, the person had no knowledge consent was revoked, and cannot be charged for something that is impossible to avoid being guilty of?
I'm not sure I entirely understand this quote to its fullest. It is being argued that it is the experience of the victim that matters if sex is consensual. Isn't this quote logically wrong? Consensual by definitions means both parties agreed. But is the author arguing that it is the victim's opinion that makes it consensual only?
How would that work in a situation where both parties start having sex, then it stops being consensual half way (from the victim changing their mind). The victim changes their minds but says nothing, and continues as before during the act. From the authors opinion, the victim experienced rape, hence the perpetrator should be convicted. But from the perpetrator's perspective they have no knowledge the partner's consent was revoked.
As far as I understand, an accusation should examine a perpetrator's perspective more, since that person is being charged with a crime. Why is the author arguing that the victim's experience is what the trial should hinge upon? If the victim raised an accusation, that is enough! It is the perpetrator that is being tried and attempted to be found guilty, hence the trial focuses on the perpetrator's actions and perspective.
Can someone better weigh in? This seems like one of those thoughts that sounds profound, but does not stand up to scrutiny.
Essencially taking the inner-most loop (that computed if a neuron would spike or not) and implementing it as a kernel in OpenCL.
Step 1 was showing increase from single-thread C++ to OpenCL kernel. Increase was 6-10x using a i7-2600k and running on all logical cores. Step 2 was implementing in FPGA. This means pre-shipping data to the FPGA while CPU calculated other things, and beginning computation on the FPGA, and receiving responses back on CPU. Performance was 75x compared to single-thread C++ code.
Important notes that I didn't expect: Bottleneck was memory transfer bandwidth across PCI-E. Power consumption was less on FPGA compared to CPU. Development time was significantly lessened. Altering the design is simple when going from OpenCL > FPGA, compared to Verilog > FPGA
No link for my thesis, can send you a pdf if you want. In terms of what was needed, my kernel was the simulation inner-most loop that would take in 4 values(2 floats, a const int and a double) per neuron and use them to update the neurons state. The simulation ran at a resolution of 1ms, with values between 1k and 100k neurons.
In essense it was high repetition, low complexity, high memory calculations.
Infact, what I experienced was that a) the biggest overhead is actually setting up the kernel and b) you have to take into account the memory requirements.
Biggest upgrades in performance came from transitioning the data transfers from synchronous to asynchronous, (to alleviate memory bottlenecks as much as possible), and from increasing the number of neurons.
Most interesting bit was that due to the simulation characteristics (Izhikevich model of a SNN), the firing rate dropped aroud 20-30k neurons. With a low firing rate, I could simulate in real-time (ie 1ms of simulation in 1ms of real time) 18k neurons, and 80k neurons due to disparities in firing rates
Having OpenCl certainly reduced dev time by around 85% id say. And that's from someone fluent with verilog, who didn't know openCL before doing this.