Gladdyu

The difference is that software compilation is a fairly local optimization process - allowing you to change/inline one bit of generated code without significantly affecting the performance of the rest of the generated code - address space is cheap. On the other hand, especially when the fpga approaches capacity, one change could cause a significant portion of the design to have to be rerouted as space is limited causing significant performance differences or not meeting the timing requirements anymore.

https://www.interactivebrokers.com/en/index.php?f=759

You'd open up a trading account, deposit funds from one country to it (generally free in EU/UK, can be done with a simple bank transfer, though can take 1-3 business days). Rather than the common use case of a brokerage account to buy stocks/invest, you place an order into their IdealPro order book they run to buy the currency you want (might have to jump through 2 trades, they don't run every single pair). Generally this is tailored at larger investors, so anything under $25k is subject to some additional fees due to being a small size (https://ibkr.info/node/1459), but still significantly less than the 0.35% TransferWise charges. The costs for you are commission (<0.2bps), potentially small size fee (1-2 bps), and crossing the bid/ask spread, which is ~0 for currencies). When that order has been filled you now have the desired currency in your account and you can transfer it back out (potentially to a different country or different account).

I'm not sure whether their fees are really that low. For transfers between your own accounts, for anything over very small amounts, I found that their 0.35% variable fee is pretty large compared to adding the funds to a brokerage account and then doing the conversion there (ie. IB charges 0.002% on currency trades, with a min of $2), and transferring back out into the desired currency.

Your gain in delta (due to the stock moving) will be offset by your loss in vega (due to the volatility coming off after the impending crash). Option fair value is a function of both underlying price and volatility, which is currently at unprecedentedly high values.

It does load it - mmap doesn't copy the file content into a buffer, it merely allows you to operate on a file as if it were in memory. Memory reads correspond to file read operations.

That'd be special relativity for you - nothing ever exceeds the speed of light, hence a corrective factor needs to be applied.

https://en.wikipedia.org/wiki/Special_relativity

If you would write a basic scheduler, at some point you'd have to await the userspace code but you wouldn't have any way to force it to stop running. If the userspace code would enter an infinite loop it would hold the kernel thread forever. Within a constrained environment, eg. the kernel itself (and even that's sufficiently complex with loadable drivers that you might end up with bad interactions) I could see some use for async await, but you'd still need to be able to preempt untrusted code.

As described in the blog post, the rust compiler generates a state machine for every async function and generates the appropriate poll methods for the state transition. This is fundamentally at odds with the preemption, which would then have to indroduce new intermediate states into the diagram which it won't be able to do at runtime.

Intel tried that with Itanium. It didn't go well.

The issue was that there wasn't a cheap riscv board that supported the privileged section of the ISA (so you can run an OS on it). This, being a microcontroller, doesn't either.

Not Google being good - Irish law has been changed such that it's no longer permitted.

"The legislation passed in Ireland in 2015 ends the use of the tax scheme for new tax plans. However, companies with established structures can continue to benefit from the old system until 2020."

https://www.investopedia.com/terms/d/double-irish-with-a-dut...

Unfortunately true exponential growth of a physical system cannot exist - it'll always be some sort of logistic model that looks exponential near x=0.

How would electromagnetism work in a world without a cross product?

https://amp.businessinsider.com/images/5271388a6bb3f7ac4756d...

https://www.youtube.com/channel/UCYO_jab_esuFRV4b17AJtAw

One example is if suddenly you would require to inherit from the same object multiple times. Example - if you have a "team" object, you might at first inherit it from a list/set (as a team could be a list of members). However, later down the line, you might also want to model backups for your team. You can't inherit from list/set again, so what are you going to do? It it much cleaner in general to avoid inheritance as much as possible and only modelling the data as internal, not publicly-accessible state (by composing smaller state objects). Inheritance on the other hand (in most languages), can make your data model more visible from the outside.

This isn't to say there aren't valid use cases for inheritance (eg. runtime polymorphism), though if something can be accomplished through composition, it's usually the better approach as it only modifies inner details of an object, and not the external interface (of which the inherited classes are part).

The most certainty you are going to get is by taking an open source processor core, and run it on an FPGA with an open toolchain. You won't be able to check the actual FPGA chip, though the risk seems minimal on that front compared to ASICs with the ISA baked in.

You will pay dearly in cost, performance and pretty much every other metric that you care about though.

I doubt those are more complex to parse than C++, as C++ parsing is undecidable.

http://blog.reverberate.org/2013/08/parsing-c-is-literally-u...

Though it might finally do away with the ever-persisting Windows error messages about "this file is already open" followed by a search through all of the processes that might have it open to terminate the offender.

Yes, but you can't install a LIDAR over a software update. They've been promising full self-driving mode and getting closer by updating the software - the owners that already have the current car won't be to thrilled if they get cut-off from the state-of-the-art in Tesla's self-driving tech.

I've attempted to run it (not with this latest release yet though) and it appeared as if calling a numpy function essentially disabled the JIT for that function, which was not acceptable for us at that point. What did seem to help curiously was wrapping the numpy function in a python function and then calling that, which seemed to prevent the JIT being disabled in the calling function.

Some NICs are able to dump data directly into the (L3) cache (DDIO on Intel), so either the L3 will have to be encrypted or the IOMMU needs to contain the crypto functionality.

The RAM does not know anything about locking, it's the cache coherence protocol. The CPU will request a cache line in exclusive state, it does the operation on the memory and ensures that during it has always been exclusive to that core. After all the other cores will observe the change (and depending on the memory model+ordering, the operations that have/will happen before and after).

Unlikely any time soon - most HFTs will have massive, battle-tested C++ code bases already. The data ownership model in HFT is usually very clear - receive packet, pass through some processing pipeline, emit packet, on the same thread. If you want to send data into another part of the system (eg. because different threads handle different securities), posting a message onto their event queue works well.

You could express an arbitrary (well-behaved) ODE as a neural network by discretizing it in timesteps, but you would not extract any additional parallelism.

In normal ODEs you can already compute each X_{i}(t)/dt in parallel, but you will still have to evaluate layer/time t completely before evaluating layer/time t+Dt as it feeds forward in both the NN and ODE case.

How would this handle systems in which the dimensionality of the hidden layers is not equal to the input dimension, as is often the case? For solving the ODE you'd need to get at least 1 sample point, which might restrict the amount of information you can capture in such a network.

Would this not require all impls to be in the same translation unit or the linker has to be explicitly aware of it?

It's in the interaction between python and malloc and also migrating to python3 made the issue mostly go away, which was sufficient for our purposes.

I'd say it's a problem in the interaction of that specific version of python with that specific malloc. From a performance perspective we could not afford to simply force malloc to only use mmap for every small allocation (as it would thrash the TLB and/or balloon memory usage).

Something they could have done inside Python is manually implement a short-lived objects space that lives entirely in pre-allocated memory, preventing the repeated allocations.

I should have mentioned that the app in particular was running python2.7 - some preliminary tests on porting to python3 seemed to indicate that the issue was significantly less severe there, though the problem only occurred very infrequently that restarting the affected processes when they started exceeding a memory threshold was a more cost-effective solution that spending ages debugging the interactions.

When I worked on a Python app that did real-time processing of (very large) lists of python dicts, merely processing them in a list comprehension caused "leaks" causing unbound virtual memory growth. The issue was that that for small allocations, eg. interned strings, malloc would use the "brk" call rather than "mmap". "brk" simply bumps the top of heap pointer, so if a more long-lived object gets allocated during the time of the comprehension it creates high-water marks in the heap.

The solution at the time was to process the large lists in smaller chunks at a time to make it less likely that a small longer lived object would be allocated in the middle, preventing later cleanup. However, a better solution would probably have been to rewrite parts of the app in a less allocation-happy language.