Jhsto

This blog series is quite good: https://hoj-senna.github.io/ashen-aetna/

Not the parent poster, but as a programmer I think it was an oversight to not formally define the VM. To me, this seems like a poor foundation to build resilient applications atop of.

EDIT: And when I mean formally define, I mean something that is machine-checkable so implementations would have a conformance suite.

$30K is the loan which is usually 1-2% APR. In Finland, which more or less copies Sweden policies, also gives you subsidized housing (50% or around 250€, which ever is less, median where I went to was around 400€ for 1bd apartment), subsidized food (2€ lunch and dinner every day of the week, median lunch when eating out is around 10€), and around another 250€ a month in general student aid. There are also a lot miscellaneous student discounts for public transportation and it is common for private companies to also offer a slight discount to students only.

To my anecdotal experience, more like a market makers dream. If you do speculative HFT then for the unexperienced you may get crushed by huge slippages when exchanges crumble under a load. Notice that exchanges in the Bitcoin world either do not, or simply don't care, to guarantee availability during spiked trading. I don't say alpha is impossible, but probably requires certain degree of comprehension.

Not really. Copied it from somewhere else where the placeholder value was 7. 1 came to my mind before 0. Zero seems like it could be UB.

You could also push static HTML pages to the git root which have, e.g.,

<meta http-equiv="refresh" content="1; url='https://news.ycombinator.com/'" />

in the header.

Any paper recommendations on the bounded halting or the topic in general?

Anyone here used dark? Any anecdotal experience report you could share?

> Can Rust be used also for compute?

It can, but it's worth noticing that the programming paradigm is different. For this reason, I would assume you are still writing a DSL within Rust which can use Rust's type checker to help you figure out what to write and how, but Rust in itself cannot represent the same semantics as-is that is required to write efficient parallel code. So, you still need to be a domain expert. But, automating the bytecode writing is alleviated by Rust's ability to provide packages etc.

I refactored some OpenMP code to run on SPIR-V using the Vulkan API the OP project uses, and I must say that I cannot see myself doing it in any other language than Rust.

Many vendors make routers which have 4G modem which then send out a WiFi signal + have Ethernet ports.

In rural areas the ADSL prices started climbing up a few years ago and most moved to cellular (60 euros for 21Mbps ADSL vs 25 euros for 50Mbps 4G). As of recent fiber connections are getting good in rural areas as well, so people are switching to fiber (40 euros for 100/100Mbps, 60 euros for 1000/1000Mbps). People who have both 4G router + fiber are quite rare.

In my experience some channels on 4G are quite ossified and during peak times you might even get a better throughput on 3G.

Sure, but compared to the 3080 I'd say that the main deal is the bigger RAM for copying reason than the increased core count.

Most parallel processing scales linearly with core count. But the 3090 is more interesting for machine learning because of its RAM, which it has 24GB against 3080's 10GB. With machine learning, you spent most of the time copying memory between the CPU and GPU, so being able to fit more data to it reduces computation latency.

You can run OpenCL kernels on Vulkan at least in theory: SPIR-V supports OpenCL memory model. CUDA might be machine translatable if you can compile into LLVM target (clang seems to have experimental support developed outside of Nvidia) which you then retarget into SPIR-V using a cross-compiler. The LLVM to SPIR-V cross-compiler however is limited in its translation for the time being.

In general, Vulkan is a thing which commands the GPU, but is not opinionated on what the language used to represent the kernel is as long as it compiles to SPIR-V. SPIR-V in itself is like parallel LLVM IR. If you look into the project source, the shaders are in GLSL which have been pre-compiled using a cross-compiler into SPIR-V. The C file you find on the project root constitutes as the loader program for the SPIR-V files.

Futhark project did some initial benchmarks on translating OpenCL to Vulkan. The results were mainly slowdowns. You can read about it in here: https://futhark-lang.org/student-projects/steffen-msc-projec...

I think this guy will have no problem getting hired. Being conscious enough to push code online works so much better than the CV preparation courses. You know you're on the right path when you are asked to play up your CV abstract than to downplay it.

Personally, I would have a hard time hiring anyone without a Github account and less so working in a place where nobody has one.

In the traditional stock market it supposedly works the same way, but the front-running is more well hidden: https://en.wikipedia.org/wiki/Flash_Boys

The way I see it is that academia and self-entrepreneurship are much alike. Comparing working in academia and for a company is apples to oranges, as working for a company is literally about working in company, i.e., not by yourself.

It's also easy to see the distinction between different phases in academia: after PhD it's much more about what could be done against what can be done. It's more like trying to get VC money with just an idea. It's hard, but some can do it, but it requires a vastly different playbook than what is required to get the degree. If you already know how to make things work, it's easier to transition into a bootstrapped mode where you can sideline as an independent researcher without all the fluff of publishing.

In a sense GPU programming is similar to cellular automata. Each cell is an invocation on the GPU, and you can assume that you may have unlimited number of these invocations. You can freeze cells infinitely or temporarily, but you cannot group them. You can assume you know the identifier number of each cell, and you can assume you know the number of cells for each program. The hard part is now to generalize algorithms in which only control structures are based on freezing, identifying, and counting of cells. The cells can communicate information to the neighboring cells, and to any arbitrary cell, but the latter is not good for performance.

Most universities don't really teach parallel algorithm development in any way despite the core count increasing in both CPU and GPU world.

Current languages like GLSL and CUDA are very abstracted in the sense that they don't really tell why some approach is better or worse than the other. To me, if you can create as general cellular automata -like solution, then such logic can be converted and is generally fine performance-wise for SIMD orientated programming.

Similar experience with IDN domains. Most places altogether reject them, but those which accept them, only a subset accept IDN recipient in the mail address.

I refactored some scikit functions to APL and I found Python inscrutable in its own way: call flow bouncing from a file to another, from Python to Cython, method shadowing, and explicit parallelization. From a productivity standpoint Python must be great as it has bunch of libraries etc., but from actually understanding what is going on, I found it frustrating to work as a OOP-investigator. Even IDEs debuggers don't help once you mix in Cython.

Learned something new today from this site: there exists motherboards specifically designed for cryptocurrency mining, e.g., https://motherboarddb.com/motherboards/920/B250%20Mining%20E...

Yet the representations are bijective, no? Doesn't it imply that (assuming a complete and consistent translator, a huge assumption I know) that any SPIR-V works as-as in WGSL?

Regardless, I appreciate your efforts. A huge disappointment that a common and shared IR could not be agreed on.

For what it's worth, HN might be interested to look into how programming a simple WebGPU calculator works. I worked on one some time ago: https://laskin.live/

Source-code is here: https://github.com/Laged/laskin.live

This way you can use some "better" API like Vulkan to run programs that are written in the new SPIR-V intermediate representation. In general, if you are interested in GPU programming, I would definitely look into WebGPU. The API is much easier to get started than Vulkan is, and achieves the most basic things required for simple GPGPU tasks (despite the fact that WebGPU can use Vulkan as the GPU API driver).

Note that WebGPU needs a browser flag to be enabled, and is generally very dangerous. It's possible to kernel panic operating systems on web page load, despite the fact that you are using a web browser.

Thanks for the correction! I don't know the details on the second iteration (assumed same applies as with the first gen), so I assume you have better information.

Also worth noting that the ring itself is not designed by Oura but by another company: https://haltian.com/reference/oura-ring/

Further, even though Oura is a private company, its financial information is public (as is any Finnish company's): https://www.finder.fi/Tuotekehitys+tutkimus-+ja+suunnittelup...

Care to elaborate? What are such safety features?

More like Excel killed APL. APL was mainly used by "domain experts", i.e., people who were not software engineers. According to Dyalog's YouTube videos, APL is still there for these people who started doing spreadsheets way before anything like Excel was available.

And don't forget the modem! Apple recently dumped Intel LTE modems as well.

Do you think that software should be architected as autonomous agents for it to scale infinitely? I watched an Alan Kay video [1] some time back. In the video, he had an argument about how software systems cannot scale unless the basis is the most complex "computation" system that we know -- that system being our own biological system.

[1]: https://www.youtube.com/watch?v=NdSD07U5uBs

It seems to be the same thing. The use-case displayed on Nokia's website matches to one of the blog-posts available on kuha.io

Coming from a software background, I think NextEPC and its new variant called Open5GS have the most down-to-earth documentation and code to start from: https://open5gs.org/open5gs/docs/. The authors have many good papers that are easy to follow. Osmocom also has good resources https://osmocom.org/projects/cellular-infrastructure/wiki

Most of the learning curve comes from the lingo. Especially now that 5G introduces softwarization of many of the network functions, the terms used by the cellular and software industries clash and may be confusing at times. But you can definitely learn the high-level idea of how the cellular networks function in this way.

For physical level things, I imagine that a degree in signal processing is required. And for more advanced software interfaces, I am afraid that you can only read about them, as most devices on which the software is implemented is proprietary. The open-source software you can find is in no-way as fully implemented as the actual software which runs commercial networks.