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

Some FDA APPROVED cancer medication cause many severe side effects, for example, Opdivo/Nivolumab[1], my father used it and it seems to help, but caused other long term side effects, which seems will never pass. 1: https://www.opdivo.com/potential-side-effects


Sounds like a very simple idea. But, no many consider to monetize it. Can you link to a sample (with a watermark or some protection of course)?


This is less useful nowdays, since magstrip are deprecated (at least in most developed countries).


Very cool and useful tool. Two pain points for me:

A) I don't see support for RTL languages (like Hebrew/Arabic) - or to configure text alignment.

B) According to a Github issue [1] it cannot be installed on a Raspberry Pi

[1] - https://github.com/silverbulletmd/silverbullet/issues/136


Is Graal VM a silver bullet? Ignoring startup times, will Graal VM out perform classic JVM (IBM/Oracle etc'). I guess the optimization of the classic JVM are hard to beat. Also, cross compile is not working with Graal VM (which makes it harder to deploy than a good old Jar file).


Startup times (especially for 'on demand' cloud workloads) are kind of the point of GraalVM. Effectively, it shifts optimisation to the compile phase. GraalVM build take much more time than classic Java. But they run a bit faster (on some workloads dramatically) and use less memory. It's no silver bullet for development, if you want fast turnaround after changing your code you want the classic JVM. GraalVM can help to cut your production load a bit (although Oracle seems to keep the heavy performance gains behind for their licensed GraalVM enterprise customers)


> But they run a bit faster (on some workloads dramatically)

That’s not true. For the majority of applications the JIT compiler will be much faster (either Graal’s JIT compiler or Hotspot). Startup time, and memory reduction is true though for AOT.


I haven't noticed compile times to be any worse when using GraalVM to build Java projects.

Caveat: I also haven't been using Native Images yet, though. So I can't comment on if it'll be dramatically different for that build target.


GraalVM is multiple projects and I feel there is often a bit of a mix-up around these:

GraalVM is first and foremost a JIT compiler written in Java that can be plugged into OpenJDK. Due to it being written in a higher level language than the original Hotspot compilers (written in C++) they are easier to write/maintain/experiment with. This mode of operation is used extensively by Twitter for example, because on their workloads it provides better performance than Hotspot, but the two trades blows in general. But this uses the standard javac compiler so it is basically just a slightly different JVM implementation.

Since a JIT compiler outputs machine code it can be “easily” modified to do so in an offline setting as well — this is Graal’s AOT/native compilation mode. This will take a long time compared to some other compilers (I don’t exactly know the reason for that, probably Java’s dynamic nature requiring more wide-reaching analysis?), but will have lower memory usage and faster startup speed compared to the traditional execution mode (but rarely better performance).

There is also Truffle, which turns “naive” language interpreters into efficient JIT compiled runtimes and allowing polyglot execution, which is a whole other dimension.


Wow, yes this definitely was not clear to me as a (longtime) user of GraalVM.

Thanks a lot @kaba0, big-O would be smart put your comment as part of the GraalVM site FAQ for "What is GraalVM".

Cheers.

EDIT: One request for a small clarification

> But this uses the standard javac compiler so it is basically just a slightly different JVM implementation.

What is "this"? Are you referring to TFA?


I use GraalVM as my standard non-native JDK (OpenJDK replacement) and I'd say the performance is somewhat better.

There are a lot of non-biased benchmarks you can find online, most of them showing that Graal (both CE/EE, though particularly EE) are more performant than OpenJDK.

You then also have the option to compile to native, or to embed/run code in other languages baked in.

It's a no-lose scenario IMO.


Are there no downsides?


It usually needs a bit longer warmup period in my experience. But for long-running processes it can be ideal, Twitter for example uses it for quite some time in production.

Also, not every GC is available, or only in the enterprise version.


Anecdotally I found that recent releases of OpenJDK with Hotspot were a bit faster. Both on my machine and for web services. If you don't need native images or truffle, the huge installation size isn't really justified.

There are multiple benchmarks that show marginal gains using GraalVM CE for big data workloads; it might make sense if you're still stuck on Java 8 or 11. The enterprise edition shows more significant gains.


Especially as, the last time I checked, more "modern" garbage collectors (e.g. G1) are only available in the enterprise edition.

The community version has only serial or nothing, which are ok for small heaps or short lived processes.


On some micros Graal beats C2, on some others it doesn't. It's not a silver bullet.

GraalVM is regular OpenJDK with the compiler switched out, AFAIK.


> GraalVM is regular OpenJDK with the compiler switched out, AFAIK.

Do you have a source for this? Or how do you know?


Just look at the 22.2 release notes [1]:

> Updated the OpenJDK release on which GraalVM Community Edition is built ...

and

> Updated the Oracle JDK release on which GraalVM Enterprise Edition is built ...

[1] https://www.graalvm.org/release-notes/22_2/


Got it, thank you @fniephaus. Really appreciate the info, and please keep up the fantastic work!


GPS spoofing will not prevent a US attack on Russia, it may prevent angry Russians from finding Putins' office, though.


What does GPS have to do with finding Putin's office?


There was an exiting legislation for 11K, so this new legislation only reduced the sum to 6K. Not sure how this law is going to be enforced (as many of the laws in Israel are not strictly enforced).


Guessing USB Rubber Ducky is an option


You make pwning lots of fun


What is the best object detection that is able to run on Raspberry PI 2? I checked tiny Yolo which requires less resources but it is much less accurate than the regular Yolo. Looking for the best accuracy with the least CPU/RAM requirements. Mainly needs this to tell if an image contain a person (still images from a network camera, which publishes an image upon motion detecion).


It would seem that it depends on the architecture you will be using. Whether is a ARM, GPU, mobile GPU processor, etc. This is comment from the author of YOLOv4 mentions that NanoDet is more suitable for ARM-CPU's https://twitter.com/alexeyab84/status/1436377831974506496


Very cool, but the desktop app for chest CT doesn't work - you can open an image but nothing get diagnosed. How is the algorithm differ from existing image classification algorithms?


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

Search: