HN user
Yes, ranking requires reducing to a single dimension where all interesting things are multi-dimensions. This is a lossy process, which often tells more about the one(s) doing the ranking than what's ranked.
Profession as sibling said, available here: https://www.inf.ufpr.br/renato/profession.html
The wikipedia entry also has link to the text but the above is nicer IMHO, just the raw text. From a previous HN discussion some weeks ago!
I'm sorry I won't share much details, I don't think much is public on Vsora architecture and don't want to breach any NDA...
From their web page Euclyd is a "many small cores" accelerator. Doing good compilation toolchains for these to get efficient results is a hard problem, see many comments on compilers for AI in this thread.
Vsora approach is much more macroscopic, and differentiated. By this I mean I don't know anything quite like it. No sea of small cores, but several more beefy units. They're programmable, but don't look like a CPU: the HW/SW interface is at a higher level. A very hand-wavy analogy with storage would be block devices vs object storage, maybe. I'm sure more details will surface when real HW arrive.
Very simplified, AI workloads need compute and communications and compute dominates inference, while communications dominate training.
Most start-ups innovate on the compute side, whereas the techno needed for state of the art communications is not common, and very low-level: plenty of analog concerns. The domain is dominated by NVidia and Broadcom today.
This is why digital start-ups tend to focus on inference. They innovate on the pure digital part, which is compute, and tend to use off-the-shelf IPs for communications, so not a differentiator and likely below the leaders.
But in most cases coupling a computation engine marketed for inference with state of the art communications would (in theory) open the way for training too. It's just that doing both together is a very high barrier. It's more practical to start with compute, and if successful there use this to improve the comms part in a second stage. All the more because everyone expects inference to be the biggest market too. So AI start-ups focus on inference first.
From Le Monde live feed, RTE (French electricity network manager) declared the issue unrelated to this fire.
"Le gestionnaire français souligne par ailleurs que cette panne n’est pas due à un incendie dans le sud de la France, entre Narbonne et Perpignan, contrairement à des informations qui circulent."
castxml (https://github.com/CastXML/CastXML) may be what you want. It uses the Clang front-end to output an XML representation of a C or C++ parse tree. It is then possible to turn this into what you want. I've used it and seen it used to generate code to do endianess conversion of structures from headers, or RPC code generation for example.
It can be used from Python through pygccxml (https://github.com/CastXML/pygccxml). The name comes from a previous instance, gccxml, based on the GCC front-end.
Both castxml and pygccxml are packaged in Debian and Ubuntu.
On the L/S unit impact: data movement is expensive, computation is cheap (relatively).
In "Computer Architecture, A Quantitative Approach" there are numbers for the now old TSMC 45nm process: A 32 bits FP multiplication takes 3.7 pJ, and a 32 bits SRAM read from an 8 kB SRAM takes 5 pJ. This is a basic SRAM, not a cache with its tag comparison and LRU logic (more expansive).
Then I have some 2015 numbers for Intel 22nm process, old too. A 64 bits FP multiplication takes 6.4 pJ, a 64 bits read/write from a small 8 kB SRAM 4.2 pJ, and from a larger 256 kB SRAM 16.7 pJ. Basic SRAM here too, not a more expansive cache.
The cost of a multiplication is quadratic, and it should be more linear for access, so the computation cost in the second example is much heavier (compare the mantissa sizes, that's what is multiplied).
The trend gets even worse with more advanced processes. Data movement is usually what matters the most now, expect for workloads with very high arithmetic intensity where computation will dominate (in practice: large enough matrix multiplications).
What's new: https://www.masteringemacs.org/article/whats-new-in-emacs-30...
Or in antinews format: https://www.gnu.org/software/emacs/manual/html_node/emacs/An...
It's a good but hard question... Because cellular is huge.
In a professional context, nobody knows it all in details. There are specializations: core network and RAN, and inside RAN protocol stack vs PHY, and in PHY algos vs implementation, etc.
You can see all the cellular specs (they're public) from there: https://www.3gpp.org/specifications-technologies/specificati...
5G (or NR) is the series 38 at the bottom. Direct access: https://www.3gpp.org/ftp/Specs/archive/38_series
It's a lot ;) But a readable introduction is the 38.300 spec, and the latest edition for the first 5G release (R15, or "f") is this one: https://www.3gpp.org/ftp/Specs/archive/38_series/38.300/3830...
It's about as readable as it can get. The PHY part is pretty awful by comparison. If you have a PHY interest, you'll need to look for technical books as the specs are quite hermetic (but it's not my field either).
LTE total latency is 20-50 ms, and you compare this to the marketing "air link only" 5G latency of 1 ms. It's apple and oranges ;)
FYI, the air link latency for LTE was given as 4-5 ms. FDD as it's the best here. The 5G improvement to 1ms would require features (URLLC) that nobody implemented and nobody will: too expensive for too niche markets.
The latency in a cellular network is mostly from the core network, not the radio link anymore. Event in 4G.
(telecom engineer, having worked on both 4G and 5G and recently out of the field)
Emacs is in the process of moving from legacy languages modes using regexps and elisp for syntax analysis to new modes using tree sitter.
In this context, what does a name like "c-mode" should mean? Options: 1) it should stick to the old mode, cc-mode here. To use the new mode, use explicitly c-ts-mode; 2) it should move to the new tree sitter mode, c-ts-mode. To use the old mode, use explicitly cc-mode; 3) it should mean the new preferred Emacs mode, with a way for the user to take back control if they have a different preference. This preferred mode will change at some point from legacy to tree sitter.
The change is (3), with a move to tree sitter in Emacs 30 (to be released soon) IIUC. It makes sense to me. Saying that anyone own a name as generic as "c-mode" in an open source project just because they're first and have a long history as a contributor (thanks by the way!) seems excessive. Change of default is normal in an evolving project, and as long as it's clearly documented with a way to override (which is the case IIUC) it's fine to me. One can dislike the change, but it's impossible to please everyone anyway. Emacs users are used to adjust configuration based on their preferences.
I understand it can be an emotional situation for the maintainer of the legacy mode. But I don't see the need to call foul play.
Hi, in case you're not already aware of the name clash, there's already a `rr` in the programming world. It's "record and replay": https://rr-project.org/.
Very different, but a very fine tool tool too.
See just above the map: "This has been age-standardized, assuming a constant age structure of the population for comparisons between countries and over time.". This is what you suggests IIUC?
Take the infinite loop as just an example of an issue with depth-first search and backtracking. To be more general, I'd say that the issue is that the overall performance of a Prolog program can be very dependent on the ordering of its rules.
As an anecdote, a long time ago for a toy project switching two rules order got the runtime to finding all solutions from ~15mn to a around the second (long time, memory fuzzy...). The difference was going into a "wrong" path and wasting a lot of time evaluating failing possibilities, vs. taking the right path and getting to the solutions very quickly.
So in practice even if Prolog is declarative to get good results you need to understand how the search is done, and organize the rules so that this search is done in the most efficient way. The runtime search is a leaky abstraction in a way ;)
It's not an issue limited to Prolog, many solvers can be helped by steering the search in the "right" way. A declarative language for constraint problem like MiniZinc provides way to pass to the solver some indication on how to best search for example.
Also, most modern Prolog support tabling, which departs from strict DFS+backtracking and can help in some cases. But here too, to get the best results may require understanding how the engine will search, including tabling.
You may want to try x2go. It uses the older NX protocol version 3, while NoMachine is at version 4. It's good enough for my use case, and support remote applications just fine: this is how I use it.
I bet it had diesel generators when it was in service with AT&T to boot.
20 to 25 years ago I visited a telecom switch center in Paris, the one under the Tuileries garden next to the Louvre. They had a huge and empty diesel generators room. They had all been replaced by a small turbine (not sure it's the right English term), just the same as what's used to power an helicopter. It was in a relatively small soundproof box, with a special vent for the exhaust, kind of lost on the side of a huge underground room.
As the guy in charge explained to us, it was much more compact and convenient. The big risk was in getting it started, this was the tricky part. Once started it was extremely reliable.
According to https://www.withouthotair.com/, no.
I wonder how (if?) this thing runs Linux.
See there: https://www.qualcomm.com/developer/blog/2024/05/upstreaming-...
Should be good after all this has landed in upstream Linux and all the distros (which may take a bit of time, as usual).
[...] the standard way to get structured output seems to be to retry the query until the stochastic language model produces expected output.
No, that would be very inefficient. At each token generation step, the LLM provides a likelihood for all the defined token based on the past context. The structured output is defined by a grammar, which defines the legal tokens for the next step. You can then take the intersection of both (ignore any token not allowed by the grammar), and then select among the authorized token based on the LLM likelihood for them in the usual way. So it's a direct constraint, and it's efficient.
For a text based version of the "tree of chats" idea, using Emacs, Org mode and gptel see `gptel-org-branching-context`in: https://github.com/karthink/gptel?tab=readme-ov-file#extra-o...
Use llamafile [1], it can be as simple as downloading a file (for mixtral, [2]), making it executable and running it. The repo README has all the info, it's simple and downloading the model is what takes the most time.
In my case I got the runtime detection issue (explained in the README "gotcha" section). Solved my running "assimilate" [3] on the downloaded llamafile.
[1] https://github.com/Mozilla-Ocho/llamafile/
[2] https://huggingface.co/jartine/Mixtral-8x7B-Instruct-v0.1-llamafile/resolve/main/mixtral-8x7b-instruct-v0.1.Q5_K_M.llamafile?download=true
[3] https://cosmo.zip/pub/cosmos/bin/assimilateYou can try running tests in parallel with the memory sanitizer (MSAN) enabled. MSAN uses a lot of memory, and on a 64 GB machine I have to reduce the amount of parallelism not to trigger Linux OoM killer.
MSAN: https://github.com/google/sanitizers/wiki/MemorySanitizerFor a given process design kit (PDK), the synthesis tool will have a few different types of transistors. They correspond to different trade-offs between size and power on one hand, and speed on the other. The fastest the transistor, the bigger it is and the more it leaks (lower voltage threshold means faster switch time, but more leakage).
For a given target frequency, the synthesis tool will always use the most efficient transistors it can. And the result is a mix, using the few available types. But the highest the frequency, the higher the proportion of faster and bigger transistors in the mix.
This is the bird's eye view and very simplified, but hopefully enough to get the idea ;)
The opposite: eSIM allows IoT devices being moved from one operator to another remotely, with no physical SIM swap. With device using physical SIM this wouldn't be economical, with eSIM remote change it can be. This allows long term users (meters, industrial connectivity, ...) not to be tied to a single MNO. They can regularly renegotiate their contract, and use competition. And the telcos really hate this, and tried to delay this happening as much as they could. Still in the end users and device makers managed to push this through the telcos throat.
Yes, using the Shor algorithm and this was achieved in... 2012 ([1], from Wikipedia).
Larger cases of quantum factorization since then used non-scalable algorithms.
The page summarizing the considered new names and their pros/cons is interesting: https://github.com/coq/coq/wiki/Alternative-names
Naming is hard...
There a built-in similar function, `fill-paragraph`, tied to M-q.
I use it routinely and it's very nice. It has some language smart, and for example understand code comments, and can format comments nicely. It also has smart to recognize line header, and reformat while keeping those headers, with possibly a different first line. So if you introduce item (unnumbered list) with a "-" for example, you can either align the second line to the "-" or to the start of the text after, your choice. `fill-paragraph` will recognize this and stick to your choice when reformatting the paragraph.
I can't compare with `par`, which I've never used. But I'm a very happy user of Emacs M-q.
I stick to 80 columns, as with it I can better use my screen space. Even on modern wide screens.
Even if some lines are long, a lot of lines are short. So the end-of-line side of a text editor is less densely used than the start of line side. This may not show too much with 80 columns line, but with longer lines one can notice that the end-of-line space is mostly blank, with low information density.
So instead of using long lines, I'm using 80 columns lines but with several (3 in practice) text panes in parallel. Basically, my work set-up is 3 columns of text panes, with 80 columns of characters each. That allows working on a module body with its header still visible, and the header of another used module shown too. Or to see two different parts of the same file easily (head with declaration, bottom with code). In other words, it's easy to find productive use for 3 parallel text panes. And each one is "information dense".
I'd like to have a little more than 80 columns. 100 would be a good number (higher waste space on the EOL side). But with this I can't fit 3 parallel panes on some screen. So I stick with 80 characters, which is OK too. 80 characters can be annoying when manually formatting code, but when using an automatic formatter (clang-format, yapf, black...) it's not such a big deal.
Anyway, there's a big subjective part in this so just use what's fine by you (and your team). Still, the information density part is an objective thing. So if you can use 3 parallel text panes with your editor, I suggest you try it. That may make you stick to 80 chars too, and not only for historical reasons ;)
That could be, the author may not have expected nor intended the exposition of an HN post. If so, my apologies. I still find the article unfair and biased in its presentation, compared to the email list discussion. It's unfortunate, because if one look the comments here it's clear many take the article at face value and haven't read the list thread.
There's a misunderstanding here: I'm not saying "don't complain". Complaining in itself is fine, and others are complaining on this topic in a way that looks OK to me (and will probably be more efficient too). It's the nature of this specific article complaint that I have a problem with.
I agree with @tarsius on this: just give the discussion (and patches) some more time, and it's likely to end just OK from past experience.