Hacker News new | past | comments | ask | show | jobs | submit | more pixelesque's comments login

Calling the 7840U 16-core is a little disingenuous IMO: it's got 8 cores, and can do SMT...


And it's definitely slower in most tasks than the M2.


Well, depending on the wavelength used and the MFP of the scattering elements (rain, fog droplets in this case) they do degrade a bit, but it'd be very unlikely to have a huge effect under 300 m.


Going to have to disagree on the lack of an index: I can see workflows where that's simpler, but I'm so used to that now with git (for better or worse) I'm imagining that'd be a pretty big workflow change for me...

Other than playing around with it, I haven't really used it in anger though, so...


It's a lot more asm instructions than the tight loop of the naive one, as it's got to track more state (working out the middle of the slice, etc)...

https://godbolt.org/z/917o7oT8r


Aha. So it could be optimized into two tight loops. The linked wikipedia on pairwise says the numpy implementation is same speed as naive


Numpy also uses blocked pairwise summation, with a block size of 128: https://github.com/numpy/numpy/blob/a6e9dc7152098182b45ecd6e... .


There was such an explosion of PIMs and PDAs in the 90s I seem to remember...

My Dad went through loads of different bits of software (paid for by work)...

I can remember Ecco, Sidekick, Packrat as names, and I'm sure there were more that were more closely tied to PDAs like Psion and Palm in the later 90s...


It allows you to defer subdivision of the mesh (maybe down to micropoly level for displacement) until the final render stage, rather than baking in the subdivision earlier and having to deal with dense geometry for things like animation where it's better to have lighter-weight meshes.


As the article points out though, normal maps don't "work" in all situations though, as they don't actually change the geometry just the lighting and the illusion of the geo, so viewed at the edges of meshes displacement is still the better high-fidelity option.

DeepBump might be able to extract 1D (height only, not full 3D vector displacement) maps to use with traditional displacement though.


If this uses pydub which uses ffmpeg under-the-hood, I guess it re-encodes the .mp3s rather than "losslessly" snipping out frames of audio without re-encoding?


That's right. Also adds a fade on the ad transitions. I haven't noticed a drop in quality.


I mean, admittedly you have to scroll down to the second half of the (long) page, but the "Code repository on Github" link goes straight to the github project page for me...

Only one of the security issues seems to be unfixed, the others all have patch versions.


It looks like it can use both traditional "tagged pointer" alignment bits AND virtual address bits...


I see that in the readme but I don't see where that's handled in the bitmasking. It appears to be universally masking high-order bits here: https://github.com/irrustible/ointers/blob/1961f75bbb9818d72...


Read the function above the function you linked to.


Oh that's frightening they shift the entire pointer by the alignment


Why? Alignment causes some low–order bits to be zero. Shifting the pointer to the right drops those zeros on the floor, leaving high–order bits zero (or sign extended or whatever). Then you can put your tag up there instead. Shifting the value left by the same amount drops the tag and recovers the same pointer for use.


My guideline with pointer tricks is: if you're not just masking bits it's too complicated for real use.


Any idea why it's preferred to do the alignment route instead of storing the bits in the upper part of the pointer & masking?


Personal preference, architectural differences, phase of the moon, etc, etc.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: