bremac

Location: San Francisco, CA

Remote: Yes

Willing to relocate: Yes

Technologies: Java, C, C++, SQL, Python, Kubernetes, Linux, perf, PostgreSQL, OCaml

Résumé/CV: http://macdonell.net/resume.pdf

Email: brendan@macdonell.net

Staff engineer with over a decade of experience leading products to successful delivery and beyond. Recently focused on high-performance streaming analytics at Sight Machine (I led the design and implementation of their stream processing engine, and before that, their data acquisition product), I can also work as a generalist backend developer or team lead.

Shoot me an email if you want to chat!

  Location: San Francisco, CA
  Remote: Yes
  Willing to relocate: Yes
  Technologies: Java, C, C++, SQL, Python, Kubernetes, Linux, perf, PostgreSQL, OCaml
  Résumé/CV: http://macdonell.net/resume.pdf
  Email: brendan@macdonell.net

Shoot me an email if you want to chat.

No management positions, please!

Unfortunately none of the hardware used for testing supports FP16 arithmetic. Between Intel and AMD, the only platform that supports AVX512-FP16 is currently Sapphire Rapids.

Value types still require allocation for types larger than 128 bits if the value is either nullable or atomic — that seems like a reasonable trade-off to me.

Keep in mind that you still need send a print job to the fake printer to trigger the exploit. If you send the job to your real printer, nothing happens.

Per the bug report, all versions since Java 8 are affected.

Unfortunately, unless the JIT can prove that the address you are accessing via the segment is non-negative, it can't elide the bounds check. See https://mail.openjdk.org/pipermail/panama-dev/2023-July/0194... for a bit more information.

As the comment you replied to indicates, both of those APIs perform bounds-checking. In certain tight loops, this can add up to quite a bit of overhead [1]. However, it's not documented, but if you really know what you are doing you can convince the JIT to elide the bounds checks for MemorySegments [2].

[1] https://mail.openjdk.org/pipermail/panama-dev/2023-July/0193...

[2] https://mail.openjdk.org/pipermail/panama-dev/2023-July/0194...

Reading between the lines, it sounds as if they're using mmap. There is no "append" operation on a memory mapping, so the file would need to be preallocated before mapping it.

If the preallocation is done using fallocate or just writing zeros, then by default it's backed by blocks on disk, and readahead must hit the disk since there is data there. On the other hand, preallocating with fallocate using FALLOC_FL_ZERO_RANGE or (often) with ftruncate() will just update the logical file length, and even if readahead is triggered it won't actually hit the disk.

I think you may have linked to the wrong graph — while that graph does have a spike on it, the spike happens when the index was broadened in May 2020 to include savings and money market accounts.

Thanks for mentioning this, I couldn't think of where I'd read about this technique before. I was remembering https://webkit.org/blog/6161/locking-in-webkit/

I think that the answer here is "not easily". To use the x32 ABI, you would need:

1. Kernel support to be enabled in order to make x32 system calls. Checking /proc/config.gz on Arch Linux, my kernel does not appear to have it enabled.

2. An x32 toolchain to build against. For gcc and glibc, that would mean re-compiling as described here: https://sourceware.org/glibc/wiki/x32

3. All of the libraries you link with to be recompiled for the x32 ABI.

x86 is definitely easier to build against since there's still legacy software using it, whereas almost nobody seems to use x32. However, over the long term I expect x86 compatibility will bit-rot too.

If you allocate a chunk on the heap with 8-byte alignment, then you can throw away the lowest 3 bits of precision, and then you can address 32GB with a 32-bit pointer.

This part is totally doable, and in fact it's one of the pointer compression modes built into the JVM: https://shipilev.net/jvm/anatomy-quarks/23-compressed-refere...

For C++, it's a really interesting thought experiment, but in practice there are a few rough edges:

1. Your debugging tools will probably struggle to interpret compressed pointers.

2. You'll need to roll your own containers too. Otherwise, vectors, strings, maps, smart pointers, etc. will still use 64-bit pointers. In my experience, containers account for most pointers in a modern C++ code base.

3. _Technically_, the representation of null pointers is implementation-defined, so truncating to 32 bits and then zero-extending is not portable: it could convert a null pointer to a non-null pointer. In practice it doesn't matter though, since every modern target uses a zero bit pattern for null pointers.

-m32 doesn't target the x32 ABI though, it targets x86. Per the manual:

The -m32 option sets int, long, and pointer types to 32 bits, and generates code that runs on any i386 system.

That restricts you to the smaller register set, removes all amd64 instructions, and uses the x86 ABI (on Linux, parameters are passed on the stack instead of in registers.) I suspect that this is why your program became slower, as opposed to using 32-bit pointers.

I'm unsure about library support, but gcc and clang support function multi-versioning (FMV), which resolves the function based on CPUID the first time the function is called.

This LWN article has some additional information: https://lwn.net/Articles/691932/

but interests of corporate mega producers they can't guarantee such thing at scale. So to protect them and people from them these laws are made kind of impossible triangle.

In North America, many of these laws were passed in the early part of the 1900s [1]. I don't think that were very many mega producers at the time, though I'd love to be proven wrong.

Also in my experience it's really hard to avoid contamination. My family farm works hard to keep their cows healthy, happy, and clean, and still has occasional issues with high somatic cell counts in their milk. It doesn't help that cows will (rarely) decide to release their bowels while you're milking them...

[1] https://www.marlerblog.com/lawyer-oped/a-legal-history-of-ra...

As someone who grew up on a dairy farm, who worked on a farm, and who has friends and family operating their own farms, I'd like to point out that this is backwards. Farmers know that bacteria can make them sick or even kill them. It's the city-slickers who have never been truly ill who think that they're harmless.

As much as I am not a fan of Applebee's, the article title on HN should probably be fixed. The executive who sent the email works for Apple Central, a mid-sized franchisee with less than fifty locations. They do not work for Applebee's itself, nor do they represent a major franchisee. (Though in this case, it sounds like their views aren't even representative of their own franchise.)

The internet is the least of your problems. The key industrial automation equipment (PLCs and IPCs) is connected directly to your machines. Higher-level control and planning functions like MES and SCADA are usually running from your server closet. You might not have access to your ERP or cloud MES system, but you can keep the lines running without them for a while. Plenty of factories have weak or flaky internet, so operating during an internet outage is hardly a novel situation.

Your bigger problem is the supply chain. After the apocalypse, I doubt you'll have an easy time sourcing cans, bulk product, spare parts, and sanitizer to run your factory. After all, each of those inputs to your process have their own complex supply chain too. And no, you're not really going to be able to scavenge these parts of manufacture them yourself, since they all have fairly fine tolerances.

In reality, I'd expect that an apocalypse will cause a reversion to a more subsistence-style lifestyle, where production and consumption are largely local and supply chains are very simple, if present at all. Computers will not help with this. I can't imagine keeping our current production processes running without all of the things required to support them.

If Putin presses on toward Poland or threatens the Baltics, then we will be on a knife's edge. However, for now, Russia has only invaded Ukraine. It's a humanitarian disaster, but so far on the world stage it shows no sign it will escalate beyond new sanctions, export controls, and perhaps additional military support for NATO members in Eastern Europe.

That's rather hyperbolic. Article 4 has been invoked six times since 2003 (including in response to the Crimean invasion.) None of those cases triggered World War III.

The legislature in my home province is closed to the public due to threats: https://www.cbc.ca/news/canada/nova-scotia/security-risk-clo...

Several MPs and MLAs have received suspicious packages: https://www.cbc.ca/news/canada/nova-scotia/mike-kelloway-sus...

"Protesters" tried to break into a federal MP's constituency office: https://www.cbc.ca/news/canada/nova-scotia/covid-19-protests...

And that's just Nova Scotia. This isn't as bad as the October Crisis, but it's still quite serious. It's not small potatoes.

As I recall, the context of those comments was in response to a purported attempt to fast-track any vaccine to be ready prior to the election. The Washington Post appears to have the same recollection [1].

[1] https://www.washingtonpost.com/politics/2021/08/05/scalises-...

For what it's worth, Peter wrote this a little more than a year before he died due to metastatic cancer. I suspect he understood quite well that time is finite.

The modern linux kernel doesn't actually write to disk when fsync is called. It buffers the writes in a cache.

Do you have a reference for this? That would break every ACID database that I'm aware of, including sqlite and postgresql. There has been a lot of work in the last few years to fix data durability issues with fsync (e.g. https://lwn.net/Articles/752063/), so I would be very surprised to hear that fsync is now a no-op.

In the case of Ruby, it's not really trying to be smart. Ruby loads everything into a single namespace, so loading multiple versions of the same dependency could cause classes, modules, etc. from version 1.1 to overwrite those already loaded by version 1.0. The dependency manager is constrained by the language. The same is true of most languages that I'm aware of, though Java can load multiple versions of the same class.

The biggest problem caused by using multiple versions of the same library is that object representations are not stable across versions. Let's say you use a library "foo" that creates and manipulates Foo objects. You want to serialize them to JSON, so you use the third-party library "foo-json". If you have foo@2.1.0 and foo-json depends on foo@1.9.7 then foo-serializers will likely fail to serialize the Foo objects created by your application. This is why npm supports peer dependency constraints, though usually they're invisible to you as a user.

There are also performance and cost issues associated with using multiple versions of each library:

1. Starting the application requires loading many of those library versions, so you will have higher start-up latency than if you only had one copy of each library.

2. If the target platform uses method-based JIT compilation (e.g. Java), each of those libraries will be compiled independently when it is used. This can cause the application to feel sluggish between the time it initially starts up and the time that all of the copies of the libraries on the hot path have been compiled.

3. The program needs to be loaded into memory to execute it. You're not only paying for more hard disk space, but also more RAM. The additional memory required can start to add up if you're running enough replicas of the application in production.

For many small applications the performance and cost issues aren't major concerns, but they can become problematic as the application grows.

13F filings don't include short positions. Given how shorted GME is, I don't think it's surprising that the total long positions exceeds the number of shares outstanding.

To add to the confusion we're still within the 45-day filing window for the end of the last quarter, so some investors may not have filed yet either.

The .net benchmarks use architecture-specific SIMD intrinsics. There's no equivalent on the JVM, though JEP 338 aims to add a vector API.

Sight Machine | Sr. Engineer (Backend) | San Francisco or Mountain View CA | Full Time | ONSITE

Sight Machine (https://sightmachine.com/) is used by some of the world’s largest manufacturers to make better, faster decisions about their production operations.

Sight Machine's data pipeline ingests streaming data from the factory floor, quality lab, and other manufacturing systems; transforms it according to customer-defined rules; and outputs data that drives our advanced analytics.

We're looking for someone to help build the next generation of the data pipeline, with a focus on performance, robustness, and extensibility.

Qualifications:

* Experience building complex data pipelines -- think realtime reporting or fraud prevention, not counting words. * 5+ years of industry experience.

To apply, visit https://jobs.lever.co/sightmachine/42be7de3-3959-48f1-a22d-7... or email hacker-news@sightmachine.com with any questions.

Scheme has the smallest (useful) language specs that I know of. For example, R5RS is 48 pages (44 if you exclude the back matter.)