solarexplorer

Did you know about HAKMEM 169? I guess it was/is not widely known since many people mention lookup tables as the only fast alternative to the popcnt instruction.

http://www.hakmem.org/#item169

Because doing so would require twice the cache and execution bandwidth. It is usually better to take the gamble and fetch just one branch. If you don't want to gamble you could stop the current thread and continue with the execution of another thread (if you have simultaneously multithreading/hyper threading).

In some cases the compiler may decide to evaluate both paths and then "undo" the path that was wrong. This is very common on VLIW architectures like Itanium which have hardware support for this (predicates), but it can also be done with other instruction sets.

If you care about performance and the number of if's you should look into profile guided optimization. This can help the compiler to arrange the code such that branches like the "if (debug)" in the example, are never taken and so don't occupy precious resources. This will also make instruction fetch faster and if the body of the if is placed on another cache line it can also improve instruction cache performance (and even TLB performance and IO performance if the unused code is placed into another page).

https://llvm.org/docs/HowToBuildWithPGO.html

This did happen a year ago https://elpais.com/politica/2019/12/13/actualidad/1576232797...

Very nice, could this be used in Apple's ecosystem? (which is based on reference counting as well?)

Well, if you don't care about security, you can always put the setuid bit on the binary (I suppose that would work?).

I agree that the situation is not ideal, but at least you can run it on your own computer if you actually want to...

In the past there were some bad actors doing shady stuff on iOS with this type of entitlement. I wonder if that influenced this type of restriction: https://guce.techcrunch.com/copyConsent?sessionId=3_cc-sessi...

I think this entitlement controls only the ability if you are not running as root. That makes perfect sense, because you don't want random user processes to be able to sniff your network traffic...

> A Boolean that indicates whether the app manages virtual network interfaces without escalating privileges to the root user.

https://developer.apple.com/documentation/bundleresources/en...

It is not the same to know something from a book or tv and experiencing it in first person. * Just ask any person from east Germany who went to the west after the wall came down. Even though they knew it all from tv etc, actually being there and seeing it themselves made a huge impression on everybody. After that the communist elites in the east were immediately powerless.

* I was one of those persons and I can assure you that it was very impressive and changed everything...

> Better be running linux on a Mac mini somewhere.

At least we could use Docker!

..and get actually reproducible builds...

In case you never tried this: pressing [control] + [command] + [space] will open an emoji picker in most (all?) places in macOS.

There is also https://tuist.io

Even trees in small parks don't appear. I think the map lists only trees near streets.

...or a backslash.

Well, actually they did try a few times. Itanic and the Intel iAPX 432 come to mind...

Often you can offload the business logic to the backend. That way you don’t have to implement it multiple times for each platform and you can change it “immediately” even if users don’t update their apps.

ARM was founded as a joint venture of Apple and VLSI. And Apple was the very first client and used an ARM processor in the Newton—the grandfather of the iPhone. So it makes a lot of sense to describe the ARM1 as an ancestor of the iphone’s processor today.

Exactly. UITableView is a good example of how _not_ to do things.

There is one already: SourceKit http://www.jpsim.com/uncovering-sourcekit/

Always a good read:

David Goldberg: What Every Computer Scientist Should Know About Floating-Point Arithmetic (1991)

https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.h...

The advantage of a feedback form is that the developer can come back to you with suggestions, ask you for details to reproduce a bug, etc. If you just go to the App Store and leave a (negative) review, there is no way for the developer to contact you. Hence the dialog/feedback form pattern. Allowing developers to respond to reviews on the App Store will help with this problem.

Something that the author seems to be missing is that traditional complexity analysis (with mathematical proofs etc) is done for Turing Machines which have one-dimensional memory (an abstract tape), and reachable memory is linear with time. Current microchips are two-dimensional, so reachable memory increases square with time. If we had three dimensional memory (stacked chips?), then reachable memory would increase cube with time.

It all depends on what kind of machine you are talking about...

The point is that in a synchronous design the delays have to be multiples of a clock cycle. Whenever a latency is not an exact multiple, the circuit is idle. And clock cycles can not be aribtrarily short because of the overhead for latching etc.

Also it takes time to schedule instructions. In a simple processor with a 5 stage pipeline you can simply stall the entire pipeline, but since you stall all other instructions too, this is costly. And in a modern superscalar out-of-order processor, stall is even more expensive and you cannot reschedule all instructions for the next cycle at the end of the previous cycle because rescheduling is too complex.

You need two additional (micro)instructions, a store and a load. Store forwarding will save you from going to the cache and back, but it won't be as fast a register forwarding.

No, it's not true. Even if L1 accesses were only 1 cycle, they would be slower. The CPU will try to execute instructions out-of-order and needs to detect dependencies and possible conflicts between instructions. This is easy with registers, if the registers are the same (have the same name), there may be conflicts or dependencies. This can be tested right after decoding the instruction. With memory it's much more complex, because the memory addresses have to be calculated before any comparisons can be made. Therefore it's much harder to reorder memory instructions. There are some exceptions, like push/pop pairs, but in general memory accesses will be significantly slower.

There is no need to jailbreak anything. Just download the apps with iTunes, unzip the ipa, and voila... you can do all the static analyzing you want.

3.3 microseconds latency for the flash at the memory bus are about 11,000 cycles latency @ 3.3GHz. That is quite a lot compared to a normal DDR latency of about 150 cycles. Of course it's much better than 100 microseconds or about 330,000 cycles for a normal SSD. I would guess that the overhead for a page fault would be around 1000 cycles.

Writing a block device for Linux so that the flash could be used as a cache or ram disk is quite easy (speaking from experience) and I assume that Diablo has already written one.

If Diablo had access to the memory controller inside the main CPU they could even run the DDR as a cache for the flash memory like some giant L4 cache. In such a scenario the DDR ram emulation would make sense...

Better than SSD but much slower than DDR memory. You could use the flash memory as cache and access it within the page fault handler at block level. That would make sense because the flash latency is much larger than the overhead of a page fault. So why access it at "bit-level" like they pretend?

(actually that would be word-level, because DDR doesn't allow bit-level access...)

It would be nice to see how their DDR interface compares to their earlier block level implementation. A memory module with latencies that are an order of magnitude greater than a pagefault seems a strange idea. Especially when the memory interface of the CPU is not aware of it.

If I understand correctly they combine a standard X86 processor with two FPGAs. One FPGA runs a custom CPU called MAP and the other manages the communication between the two CPUs, memory and other boards/peripherals. The develoment system accepts standard C/C++ code and emits two programs: one for the X86 processor, one for the MAP processor and a hardware description to adapt the MAP processor to the specific requirements of the source program. For some programs this can be a big win (and for others not so much).

The separate CPU is much faster, because it has an entire die for itself and because it is a high-volume off-the-shelf chip. An embedded CPU/FPGA will suffer much more when it executes the serial part of the application on the embedded CPU. So if you remember Amdahls law...

> What are the applications for this hybrid?

Highly parallel applications with tight loops. These loops can be offloaded to the FPGA while the rest of the system can run as before. This approach allows you to use languages like FORTRAN/C/C++ without resorting to Verilog/VHDL, so it's much easier to adopt.