Do you know if this is still true with the newer "concurrent" garbage collector in more recent Mono versions? I work on an audio player app rather than games, but also have problems with the GC in Mono on IOS. We're hopeful that eventually they'll go away, but haven't tried again recently.
I am not certain. Theoretically, it should be better, because I think they implemented a GC algorithm similar to the one on Windows. But I have never actually run it.
It's hard to emphasize how bad the Unity Mono GC is. It's a Mark-and-Sweep garbage collector, which is like the simplest-yet-least performant approach to GC there is. Nearly every other GC in production use in other stacks is better.
I'm willing to bet that Mono GC has improved a lot, but I don't think that Unity frequently updates the runtime. It's kind of painful, from what I've been told.
We are collaborating with Unity to assist on upgrading not only their runtime but also to adopt the latest and greatest GC.
Additionally in C# 7, 7.1 and the upcoming 7.x series there are many improvements that reduce object allocation (like ref structs, value type tasks and others)
Unity is just now updating the runtime for the first time in seven years. I think only the 2017.x releases have the new Mono, and most platforms use their IL2CPP AoT compiler I believe
Have you tried implementing the length extension attacks?
Truncating from 512 bits to 256 bits hides 256 bits of the state from the attacker, so in order to use a length extension attack they would need to "guess" those bits.
There are two forms of length extension, one where the attacker does know those bits. SHA-512/256 doesn't protect against that. (HMAC does, I believe.)
In addition to being a better analogy, I am told it is possible to replicate the effect with a physical capacitor and a gas-discharge lamp: https://news.ycombinator.com/item?id=4600996
SHA-256 truncated to 224 bits is vulnerable to length extension attacks if the attacker can brute force the remaining 32 bits of the state. Some use cases will make this possible or practical, some will not. It depends on the details of the problem being solved.
HFT firms are make money by taking a spread, which is effectively the cost of making a single trade. As they compete and get better and better at there jobs, this spread well be reduced, the amount of money available to pay for the best and brightest programmers will come down, and they'll suck fewer of them away from other parts of the economy.
The point being, the further they go past this 'point of diminishing returns', the less money they can possibly make. To the extent that HFT is a zero sum game, there will always be a limit on how much money they can spend.
(I believe but cannot prove that this limiting effect has already started, HFT firms are consolidating and making thinner margins than they used to)
That's a good point, but would that happen quickly enough to undo whatever brain drain problems the industry creates?
Nearly all hedge funds still take 2/20 for example, and their returns have been questionable for a decade, so idk we have reason to have faith in high finance's ability to self correct.
Is your suffix array implementation open source/available online anywhere? I'm always curious to see what other people's version of these sorts of things look like.
(I wrote an implementation of Ukkonen's suffix tree algorithm in C as maybe my second C program, it was pretty frustrating for a long time)
> (I wrote an implementation of Ukkonen's suffix tree algorithm in C as maybe my second C program, it was pretty frustrating for a long time)
Oh dear. You are brave. I briefly considered implementing Ukkonen's algorithm, but ran away scared. :-)
The reason why I wrote the SAIS implementation was because I am generally interested in text search, and because I was interested in exploring the idea of building an index around suffix arrays. Once I finished my implementation and realized that the cutting edge SACA algorithm (at the time) was as slow as it was, I mostly gave up that idea.
Since then, I've been itching to find use cases for it. As a former computational biologist, I'm familiar with how they are used in that field, but I've been looking for other places as well. Haven't found one yet, although I can think of some specialized (hypothetical) things where it might be useful.
They solve different problems. In particular, ripgrep and friends are designed to search arbitrary and potentially large directories with no pre-computation. They run in time ~linear in the size of the files to be searched.
The paper under discussion here is about a new way to create an index that also takes time ~linear in the size of the files to be searched, although presumably with a higher constant factor than just searching those files. After you have the index it's possible to search it in time linear in the length of the query rather than the files. This is much faster, but requires storing an index that is at least as large as the original file set, and keeping it up to date as things are changed etc.
Can you retrieve the original file from the index? If yes it's maybe interesting to store files like that for some databases by default and retrieve the original file only when needed.
I haven't read this paper, and haven't worked with the compressed variety of suffix trees/arrays. That said, I'm confident it's possible to retrieve the original file from a normal suffix tree, although it would be pretty slow. I imagine it must be possible to retrieve the file from the compressed version as well.
If nothing else, I think it is possible to retrieve a complete file from any index that lets you search for substrings and get a full string and position in the file back. Just search for all length 1 substrings, get a map from position -> string, then reconstruct the file from that.
I doubt it's worth storing files this way, because turning the index back into the file sounds very slow. I'd rather just store the file and the index, the time v. space tradeoff seems like a good one if you really care about search performance. That said, I use The Silver Searcher, and it's fast enough with no index that I don't think any of this stuff is worth the effort for searching text files on a file system.
What's the difference between the seller owing me money back and me having a property right in that money? They seem similar to my not-at-all-a-lawyer intuition, what am I missing?
The former is a debt you have the right to collect from the seller. The latter is actual ownership of the money. E.g. if you're behind on your cell phone bill, you owe the company money, but they don't automatically have a property right in your bank account.
This may be a reason why, but it's not a great one. The vast majority of people employed in the US with "engineer" in their job title are not Professional Engineers.
I'm talking about folks that call themselves engineers, where they clearly are not. A PE has an exam with credential requirements and an apprenticeship under another PE for a period of time + having to retake that PE exam in order to get that designation. I COMPLETELY understand the PE part of it. It's the software developers that use the title of engineer that irks me. Or HR folks baiting software developers with a title of "engineer" when they clearly are NOT qualified to be that - both by credentials or by the PE designation. Engineers are engineers, scientists are scientists (and equally less qualified in comparison to engineers). Are scientists important? Absolutely .. for me, it's more about the semantics of use and the validation of it.
I wasn't particularly talking about software engineers. I have a mechanical engineering degree, and none of the ~20ish engineers at the first place I worked had a PE licence. If you want "engineer" in a job title to mean "has a PE licence", you're going to need to change the title of perhaps 95% of people currently employed in mechanical or electrical engineering. Probably more than ninety percent of aerospace engineers too. There is maybe an argument to be made that programming shouldn't be called "software engineering", but this really isn't it.
Also for whatever it is worth, I've now worked in mechanical engineering for 5 years and software for about 1 year, and they both feel the same to me. Software is sometimes faster and sloppier, but I think that's just because the build process for a program takes minutes and the build process for the CVD machines I used to design takes months.
Well, good luck with that. Back when I was in the oil business, there were even mud engineers--or mud salesmen as the toolpushers called them.
I certainly don't favor the idea that every software engineer/consulting engineer/etc. should have to get a PE before they can call themselves by that title.
You're welcome to feel differently but don't expect a lot of support.
In one of the Mill talks, I've long since forgotten which, someone asks Ivan Godard a question about RISC. His response is something like "there was a brief window in the eighties where if you had a RISC machine you could get the whole computer onto one chip." I don't enough experience to know if this is right, but it strikes me as a nice clean explanation. It also explains why x86 won since then, because a couple generations later it was possible to get the whole computer onto one chip with x86 as well.
(I may have misquoted badly, in particular I'm not sure about the dates)
Your dates sound about right. The eighties. Mead+Conway was just out and fabs of a certain size became accessible. The question then was what could you do with these fabs and transistor budgets? Berkeley+Stanford did RISC+MIPS. Clark did the Geometry Engine at Stanford+SGI.
So what could you do with X transistors? But then X became stupid large. The 68000 (1979) had 40,000 transistors. Now the Apple A10 has 3.3-billion transistors. So you can imagine that architectural design assumptions dating from 1980 will need to be revisited.
Where did you get that figure? I'm curious because the figure I've seen tossed around is 68,000 transistors (the story going that this is where the model number came from).
It's much more likely (like infinitely more likely) that the 68000 name stems from the earlier 6800 8-bit product line. There's nothing definitive saying 68,000 transistors and I've read both 40,000 and 68,000. I believe that 68,000 was just marketing. FWIW, Motorola also employed 68,000 people in 1980 (approximately):
This was also the very brief time when memory was actually faster than the core, making it possible to contemplate things like large fixed-with instruction encodings, since the main bottleneck with the early CISCs was instruction decoding and not fetch bandwidth; it is unlikely that, had this period not existed, RISC would have developed in the way that it had.
It's ironic that Ditzel went from Berkeley RISC to Bell Labs and helped develop CRISP [1]. This was the invention of the Decoded Instruction Cache which solved the fetch/decode bandwidth problem. You could have a CISC and not have to worry about decode bandwidth. You could have a wide μop and not have to worry about fetch bandwidth.
My own understanding is more simple... people care mostly about application availability and x86 was chosen as the primary platform for Microsoft Windows so anything that didn't support the x86 instruction set was at a disadvantage. These days with interpreted or JIT compilation, things are less certain but those days running things on bare metal mattered.
